关于公司项目使用mvvm的一些思考

最近，公司的项目改版2.0。从原来的无架构换成了mvvm，经过了两个星期的开发，对于新的架构，有了自己的一些看法。

使用了android 的databinding上手起来不是特别难，基本看一遍官网的教程也就能领会了。学习成本不大。但是在开发中，会出现编译器相关的一些错误，但没有强迫症的话应该都能克服。先说说我们现在用的架构吧，我们把mvvm中的vm也就是view-model当做controller去处理（有点像jsp）界面的数据和所有的业务逻辑写到了vm中，下面是网络接口。view层使用databinding并不够深入。比方说，一个activity就会有一个xml与之对应，通常来说这个xml会绑定一格control和一个context， 这个control就是对应的是vm、 context就是这个activity。包结构没有按照功能分开，而是将所有的control放到一块。

Paste_Image.png

按照上面的简单描述，我们在开发中会碰见一些问题

• 因为一个actiivty对应一个xml对应一个vm。这样导致view的复用成了困难。
  栗子：按照之上的架构设计，大多数的xml都会对应一个activity和一个vm，由于xml的一些控件绑定了一个特定业务逻辑的vm，这样，我们在有一个业务逻辑有些许差别但是界面显示相同的业务线时，想复用相同的view成了困难，因为这个xml已经被一个业务死死的绑定在一块。无奈！我们在做这种只有些许差别的新业务时，无法对view进行有效的服用
• 针对于上一点，要是我们的view不同，但是业务逻辑相同（这种情况在我们的实际项目中也是出现过的），上述架构可以将vm（control）复用。但是这种情况往往伴随着新的需求的变化，我们不得不在之前的vm中加上针对于两种view显示的变量，来处理两个view的不同。（我们公司的产品需求变化速度异常快，很有可能在几个礼拜之后，两个业务逻辑差距会变得越来越大，这时的复用也就毫无意义了）
• 这个设计与之前的相比较下而言， 只是把放在activity里的逻辑放到了vm中来，并使用了android的databinding来减少代码量，并未达到实质的效果，业务逻辑还是一堆一堆，并且，还把一小部分view的逻辑放到了xml中， 这样，view 的逻辑一部分在activity里， 一部分在xml中，更新view的数据在vm中，并且， 不能保证在开发的时候databinding都是方便使用，有的时候强行的使用databinding，数据也只是在vm中转了一圈，最后设置view的逻辑还是在activity中
• view组件没有复用，我也不知道为什么，貌似公司不太注重代码的复用性和view的组件化，之前的项目更是特别，所有的组件用法，出现的形式都一样，并且每个页面都有，我们也要在每个activity中写一遍， 对于之前的项目也算是一个中型项目了，功能也都特别多，改起来每个类都要动，特别费劲，也就放弃了。

以上四点就是我在新的项目中发现的几点我认为在开发中特别扭的地方，问题主集中在了vm与逻辑相关，xml却又绑定了这个vm，导致复用成了问题；vm的逻辑过多（回调，内部类太多、代码太乱）；view组件无组件化思想，xml结构复杂。

其实，避免以上的问题，处理方案并不复杂。在现在的vm（control）父类再加上一层viewmodel，这个vm只与view相关， 不参与任何的业务逻辑。业务的model作为这种viewmodel的子类。并且vm应该细化到view的每一个组件，这样baseviewmodel中可以包含一些组件的vm，组成一个 功能完成的viewmodel。
具体的业务实现在viewmodel的子类去完成，尽量使用rxandroid这种框架，在项目中，由于种种原因，客户端有事会访问四五个接口之后，才拿到想要的数据；有时，获取的信息需要客户端进行处理，排序，挑选，甚至假的分页处理。只要是写业务逻辑，代码就是一层一层的回调，中间插入这无数多的错误处理，简直醉了。想我们这种‘不喜欢‘’用接口隔离，使用rx是最佳的选择了

Paste_Image.png

上面的图例说明了对于现在存在问题架构的改进

总结一下

• 组件化view
• vm只与视图有关
• 具体业务放在vm子类实现
• 尽量使用响应式框架