MVC架构模式杂谈
model－view－controller是MVC的缩写，自从二十世纪八十年代被发明出来之后到现在，想必每一个为应用编程的Coder都有一定的认知，而经过这么多年的发展，对于一种从实际开发中抽象出来的代码设计思想，在没有标准的情况下，其定义也是模糊不清的，于是也衍生出例如MVVM、MVP和一些MVC的变种。
但万变不离其宗，这些设计思想，我认为其本质是为了让项目在后续开发中具有良好的可扩展、可维护、可测试和高内聚低耦合等特性。
那么我们再看看MVC的具体所指。
- Model ：模型，通常与数据相关
- View ：视图，通常与UI相关
- Controller ：控制器，通常与业务逻辑相关
毫无疑问，这么看上去，MVC简直无敌了，几乎所有的项目都可以直接套进去，看来Coders有了这神器可以省心很多了不是？
未必，作为Geek，作为Developer，作为Coder，甚至作为PM，都不能把事情看表面，任何事物在剥离了其表面的现象直看本质才是真理，有句话叫不忘本心，方得始终不是？
我们使用MVC本意其实是为了能让项目能在后续开发中能更好分工，更好迭代，更好追踪出现的bug并迅速解决，所以在选择了架构甚至一些框架后，需要注意的事情才刚刚开始。
可以注意到，MVC本身定义其实挺模糊的，而大众对于这三部分的意义也各自有一些轻微的出入，但基本上，我们都遵循着这一种数据输入输出的路线即：
- 用户从UI(View)触发事件
- 应用内部对事件进行处理(Controller)
- 对数据(Model)的增删改查
- 结果往UI上发
- UI(View)进行相应的改变
在这种情况下，有些地方是非常明确的，但也有些地方很模糊且可操作性也很大，从而导致当项目迭代得越来越大的时候，Coder会变的越来越难受，而问题就出在黑与白之间的灰色地带－－－View与Model之间的Controller中。
无论View还是Model，在数据的输入输出中，正常情况下都没有在Controller这一块中耗费的精力多，Controller作为业务逻辑处理，将会不断因为添加新功能而变得越来越臃肿，从而变得难以维护，而且有时候，可能会因为业务逻辑与数据处理之间并没有太明显的界线，导致有可能让Controller与Model之间的耦合变得越来越大，最后导致无论是追踪bug或是开发，都变得越来越痛苦。
所以MVP和MVVM甚至一些变种MVC(例如胖Model瘦Model或是胖Controller什么的)就出现了，对于这种情况的出现，在项目变大的时候是不可回避的，也不是说用MVP和MVVM甚至一些MVC的变种就一定比MVC好，个人认为这些架构思想其实都没错，重点是怎么在矛盾中寻求进步。
在开发中，我会把开发好一个项目想象成打一场战争。
- 架构模式会被我归类为战略
- 设计模式会被我归类为战术
- 语法利用会被我归类为战斗
然而这是一场永远都没法胜利的战争(假如一直都在这三个方面都做得很好，那么这份代码就能一直走下去)，但却要无时无刻地注意不要输。
我们总不能把架构模式这样的战略用到战术甚至战斗中去的，要把架构模式战略中的缺陷这个坑填掉，就需要多变的设计模式战术(观察者模式、工厂模式、装饰模式、适配器模式等等，会有后续篇章讲解)来解决，甚至多种设计模式战术混合使用，当然，设计模式作为战术也是有缺陷的(例如强引用导致的问题)，至于语法利用这一方面就只能看所使用的语言所掌握的特性了，作为一名Coder是应该要有Coder的自我修养的，或许有时候PM会在耳边催促着功能，而你也肯定知道怎么做的快，但是饮鸠止渴的事情受害的还是自己，当然也不能说为了代码就不顾项目进度了，当中的权衡才是一场战争在Coder手中操纵的艺术。
最后，我觉得其实一开始就用MVC，那么就一直坚持MVC就好了，没必要说看见MVVC好像挺流行挺火的，然后就改成MVVM，其实项目大了以后，用什么模式都一样要面对类似战争的宏观微观的问题，只是迟早的问题，假如又一天，真的感觉战争快要输了，那么或许好好学学Android或Kernel的架构思想，然后给自己的项目进行重构，项目还是能重新焕发活力的，毕竟无论是Android还是Kernel的代码都开源并且代码量如此的大如此的久的迭代都没把战争输了，凭什么自己就觉得要输了呢？