MVC就是个选择题

由于采用了Web开发框架来开发项目，所以我首次在真正的项目中采用MVC的开发模式。随着项目的不断深入，我也在不断反思，MVC设计模式到底给项目带来了什么？成倍的开发时间？复杂无比的目录结构？铺天盖地的文件数量？听起来都很难听对吗，但是确实如此。那么MVC所许诺的那些好处呢？清晰的代码结构，易于维护，易于扩展？真有吗？

当然，我不是在批判MVC，只是觉得，在使用MVC过程中，还是需要投入更深入的思考，到底怎样才能用好这个设计模式。MVC给我的感觉是，要求使用其的开发者有更高的觉悟，来正确选择存放一段代码的地方。从而实现解耦合，代码复用，和易于维护。为什么说使用MVC会有成倍的开发时间，主要就是因为在开发中，我们需要更多的时间去思考，这些代码放在哪里更合理一些。在MVC框架下代码被切割成一个又一个的小文件，分散在复杂的目录树中，那么到底怎样选择把代码写在哪里呢？这道选择题，并非有看起来那么容易。就我个人感受而言，更多的时候，无论将代码放在哪里都可以正确实现你的逻辑，MVC不是什么神兵利器，并不能通过其模式本身的约束，将开发者导入到一个正确的轨道上，反而会因为开发者本身错误的选择而让MVC自己变得一团糟。所以说，当一个团队确定要在一个项目中引入MVC时候，应该思考一下，每个团队成员是不是真的都有能力驾驭，如果没有对应的能力话，是不是要考虑前期对项目成员进行一定的培训。

可能我说得话很装逼，但是我绝对不敢以一个专家的身份站到这里来说话，我只是一个初学者，我要把我的学习感受说出来。现在回归到MVC上，Controller给我的印象是一个协调者的形象，它知道谁能干什么，然后分配任务，构造哪个对象，初始化哪个视图，是Controller应该决定的事情。Model呢，应该是一个实干家的形象，负责所有肮脏而又细致的事情，所以我在编码实践中，将所有的业务逻辑都塞进Model里面，对Controller，提供一个简单接口，对Views，输出纯数据。View则是一个消费者的形象，给其的数据都是纯粹的，直接显示即可以。以上是我对MVC这道选择题给出的一个答案，当然我不是很确定这样做很对。

我在项目中就看到过这样的代码，将Model做成了一个工具箱，实际上是一个有各种方法的对象，每个方法看起来也提供了简单的调用接口，实际跟Controller配合时候呢，由Controller来操纵功能，安排各个方法被调用的顺序。这等于是由Controller来执行业务逻辑，但是却又对其封装了每个步骤的细节。而我个人倾向于连业务逻辑也对Controller封装。这两种选择各有优劣，而实际上从短期也难看出来谁更胜一筹。甚至，等项目上线后，最终也没法发现哪个做法更优一点。

所以说，MVC真的就是一个选择题。你有多重选择来实现同一个目的。我列举的例子只是九牛一毛，在实际项目开发中，还面临着更多的选择问题。我想，到底怎样交出自己的答案，还是应该在实践过程中不断积累，不断优化。我们只要把握好一些原则，就可以让自己不要偏离航向太远。第一，可维护性，代码逻辑一目了然应该是写代码时候的第一追求，因为看别人的代码是非常痛苦的，甚至最后回头来看自己写过的代码可能都会很痛苦，保持代码一目了然才是最重要的，给别人，给自己节省下时间。第二，可复用性，写内聚度高的代码，减少依赖，判定很简单，我写的这个代码，拷贝到别的项目里，是不是直接就能用，时刻问自己这个问题，就能保持代码的高内聚度。第三，封装变化，这个原则总体来说很难把握住，我自己的体会就是尽可能提供一个强大的接口，如果XXX改变了，那么调用我写的函数是不是格式不变？如果你写的函数，一会儿增加个参数，一会减少个参数，那么所有调用的地方都会跟着变化修改。

就到此为止了，一些愚见，请大家指正。