controller减负记录（一）

									2018.12.13
									Morris_

前言

如果在一个界面中，有多复杂的业务的话，怎么去抽离业务，实现功能解耦是个很有技术含量的问题。

MVC仍然可以满足我们的业务需求的，就看我们怎么去用好MVC。

如何抽离业务代码？

下面试一些猜想，看看罢。

使用分类如何？

苹果的官方提供的分类中的建议：

Distribute the implementation of your own classes into separate source files—for example, you could group the methods of a large class into several categories and put each category in a different file.

将一个类的实现，放在不同的分类文件中，会如何呢？我们平时对分类的使用是单一功能来扩展给类方法，像这种业务功能代码使用分类不妨尝试一下。

于是乎，我的功能分类产生了，根据不同功能给controller写了几个分类，文档功能有文档的分类，互动功能有互动的分类…

这样总算是业务实现了，原controller中代码也“少”了，各个功能块的实现也抽离出来了。

但是发现了新的问题：

1、controller的头文件中需要暴露很多属性

由于controller的分类中需要使用员controller的属性，导致controller的头文件中有很多public的属性。

2、controller的头文件中需要暴露很多方法

简单理解为，主类和分类方法互相调用的问题。分类是服务主类的，在分类实现Api后，需要通知主类，直接调用主类的方法。这样，主类调用了一个分类的Api后，执行某个操作，分类又调用主类的Api，来回使得方法调用逻辑查起来比较不直观。

3、数据问题

分类需要使用主类的数据。

可能到这里很多开发的童鞋会问，分类难道是这么用的吗？

这样使用分类可能是违背了分类的单一功能，但是也未必不能这样用啊，你看看苹果的官方文档就告诉开发者，将一个类的实现放在不同的文件中，我也有见过有项目这样写，但是有如上问题，总是让人感觉很不爽是不是。

可能是我用的不好吧，但是回头想想，看看苹果的官方文档中，公共的Api和属性也是很多，也没影响其功能和使用App的性能啊，基于这一点我更加确信，我没用好分类罢了，但是这个抽离的思想也是一种思路，可以尝试做到更好。

使用一些设计模式？

MVP如何？MVVM呢？viewModel可以实现一些业务的抽离。

• 关于MVC、MVVM、MVP

使用多个viewModel

既然业务功能多，不妨多来几个viewModel来实现各自的功能，文档功能、互动功能…这些viewModel用来处理一些业务和管理与此业务相关的数据层、网络请求等，通过代理的方式将处理完后的结果回调至cotroller中，controller再做出反应。

后记

虽然使用MVVM可以实现controller减“负”，但是viewModel层又很“厚”，本次项目我是结合分类和viewModel的形式，再加上使用分控制器，以此来给controller减负，业务功能实现了，功能也算稳定。但是不完美，肯定还有其他更好的实现方案。

其实归根结底，回调MVC设计模式上来了，对于M不要只是片面的理解为只是“数据模型”，M再处理数据外，也可以处理一些业务，M担任的业务逻辑多了，也就不仅仅是数据模型或者仅仅是业务模型了。当然也可以将业务模型和数据模型分开处理。

对于设计模式的使用，100个人有100个看法，没有最好，只有更好。

归根结底，还是需要从代码设计结构上入手：controller减负记录（二）

重属软文，言不达意，之所以不删除是为了记录自己对问题的思考问题，从1到2的这么个过程。

controller减负记录（一）
controller减负记录（一）