【.com原创稿件】2007年第一代iPhone的发布，开启了智能手机的新纪元。迄今为止，移动开发已经跨越了十年，这十年发生了太多的变化。随着移动互联网的飞速发展，人们的生活方式也在日新月异。生活单调的人们也开始注重健康的生活方式。以个性化、社会化、碎片化的方式，鼓励人们养成良好的运动习惯和生活方式，从而获得身体健康。在本次主办的2017WOTA全球架构与运维技术峰会上，咕咚技术总监唐平林先生分享了以《第十年的选择》为主题的演讲。作为国内最大的体育社交服务平台，咕咚的APP需要绑定很多手机硬件，基本上用到了手机里所有的芯片和传感器。因此，相较于其他APP，在架构的选择上会更加保守。为了兼顾与手机硬件的绑定，咕咚几乎没有使用ReactNative等动态技术。为了保证系统的稳定性，咕咚更倾向于选择原生实现。保守的架构实现会比较复杂，咕咚就面临这样的问题。咕咚首先选择了MVC框架。经典的MVC与Apple的MVC不一样。Apple的MVC中的Model（数据管理器）、View（数据展示器）、Controller（数据处理器）是相互关联的，这样所有对Model的操作都要经过Controller，这样Controller就会越来越大。在经典的MVC中，View和Controller可以是同性的，但Apple的不是。CocoaMVC=MVC+DataService缺少了View和Model之间的联系，这就是为什么Apple架构中的Controller会越来越大，最终导致非常大的问题。FatModel包含一些薄弱的业务逻辑。fatmodel的目的是controller从fatmodel中获取到数据后，可以直接将数据应用到view上，不需要额外的操作或者只需要很少的操作。瘦模型只负责业务数据的表达，所有业务无论强弱，都交给Controller处理。瘦模型的目的是千方百计写出细粒度的模型，支持各种辅助类或方法对弱业务进行抽象，而强业务还是交给Controller处理。一旦选择了胖模型，Controller拿到数据后，不需要做太多的选择就可以在Controller中展示数据。咕咚有时为了选择，也会使用瘦Model，但不敢往Model里面写任何业务逻辑，只是把Model作为存储数据的目的。这个时候业务处理还是需要Controller的。其实这两种设定没有什么区别，只是对于咕咚来说，胖模更合适。无论是服务端、前端还是客户端，采集模式都是开发者最常用的，数据也比较齐全。但是，MVC架构导致耦合度高，代码复杂。为了解决这个问题，引入下一个架构。在MVC中，如何划分代码更加清晰合理。唐平林先生认为，“严格把Model做成fatModel”，这样ViewController就可以不用做复杂的程序就可以获取数据。但是有时候在设计框架的时候，并没有严格的设计。这时候就需要引入另一种模式，MVVM。它只做一件事，就是拆解ViewController，将ViewController拆解成ViewModel，把之前Controller对Model的控制代码全部放到ViewModel中。这样，业务逻辑会非常清晰，框架也会更加明显。ViewController只做展示，ViewModel做业务处理。模型可以设计为胖模型或瘦模型。如果设计成胖Model，可以把最简单的逻辑放在ModelToprocess中，如果设计成thinModel，可以把所有数据放到ViewModel中处理。MVVM的ViewController不像MVC中的ViewController。MVVM就是ViewController+View，都统一在一层，这一层都是展示的逻辑。值得注意的是，在做view层和ViewModel层的时候，两者之间使用了一种数据绑定技术。要实现这种数据绑定，是无法借助第三方库来补充的。ViewModel的作用是处理业务逻辑。除了被View层持有外，它还会持有Model。简而言之，ViewModel是一种自上而下的相互持久化关系。在MVC架构中，三者往往相互牵制。对于开发过程，Model、Controller、View之间可能会相互交互。保持关系。从MVC到MVVM，当程序变得越来越复杂时，开发者必须严格定义每个工作模块应该做什么。只有这样，代码才能更清晰、更可靠。唐平林老师在此奉劝大家，“希望大家在以后的工作中，在项目组中倾向于使用比较简单的MVC结构，但是在开始项目的时候一定要严格区分三者之间的关系，三者之中，什么是代码可以写，什么代码不可以写，里面应该放什么代码，比如我的Model里面一定要用胖Model，一定不能在Controller里面操作View层的动画View一定不要写用户和业务相关的逻辑代码，做好这三件事，我们还是可以用MVC做架构的。【原创稿件，合作网站转载请注明原作者及出处.com】
