看懂MVC,到合理应用MVC的距离

  接触MVC模式有一年多的时间了,之后做过的几个小项目,都一直是应用的这种模式开发的。前些天有人问我，给我看他们画了一部分的UML图，类图、时序图，他们的困惑是不清楚在系统设计初期有关建模的一些细节该如何处理，比如时序图中各个层之间方法类该如何摆放位置、架构图中各层的关系等。

 

         一个没有开发经验的人来学习MVC模式，看到的都是文字，看懂的都是理论；换之，有过一些分层的实际开发经验之后，再来看这些东西。理解的深度，真就可以说是天差地别。

   

         外求带动内需，有人向我请教MVC如何分层、各层之间怎样分配职责才更合理。这其中有着一部分是我也不曾深入探究、理解到位的。在此，我也很感谢那些人，让我有所深入的学习。

 

        现在MVC模式思想深入人心，不知道它的开发人员已经很少了。面对现在行业内的开发模式，有很多种，可以说是年年有新意，但其中核心的部分是不会变动太多的，高效、稳定、易扩展，这就是核心的东西。

 

 

        以下部分转自《从三层架构到MVC,MVP》.

 

    

 

     因为VIEW中的逻辑比较简单，所以对系统复杂性的考虑基本上要重点放在Model中，而Controller是对业务流程的控制，其应该保持“代码清爽”。说是这么说，但实际进行项目开发时这两者之间的界线能这么清楚吗，答案是“尽量保（坚）持”。必定这是MVC的“特色”嘛。

 

    想知道哪些系统方法要放在MODEL中，哪些该归入控制逻辑中，感兴趣的话可以看看这个链接, 采用[ICONIX] 方法实践BLOG设计之四 [健壮性分析] .

    

         其核心内容如下： 

    实体对象(entity object):

     通常是来自域模型中的对象(也就是现实世界)，它常对应于数据库表和文件，这些数据表和文件中存储了执行用例所需的数据。有些实体对象是“临时”对象（如搜索结果），当用例   结束后将消失。

       边界对象(boundary object)：

     参与者使用它来同系统交互，这通常包含窗口，屏幕，对话框和菜单。如果有GUI原型，将会知道许多主要的边界对象是什么。

       控制对象(control object):

     将边界对象和实体对象关联起来（通常被称为控制器，因为它们通常不是真正的对象），它包含了大部分应用逻辑，它们在用户和存储的数据之间架起一座桥梁。控制对象中包含经常   修改的业务规则和策略。这样修改只需要在这些对象中进行，而不会涉及到用户界面和数据库模式。控制器偶尔 (20%的时间内)也会是设计中的“真正对象”，但大部分时间内，控制器只是一个占位符，用于避免您遗漏用例要求的任何功能和系统行为。

  

     上面的三个对象分别对应Model, View, Controller.

    

     正如文中所说，该方法还提供了如下好处：   

      1.它帮助您确保用例文本的正确性，且没有指定不合理或不可能的行为 (基于要使用的一组对象)，从而提供了健康性检查。

      2.帮助确保用例考虑了所有必需的分支流程，从而提供了完整性和正确性检查。

      3.让您能够(持续)发现对象，因为在域建模期间可能会遗漏一些对象， 而这些对象在绘制时序图时不易被发现，并且很可能正是它导致无法绘制时序图。

     4.缩小分析和设计的鸿沟，从而最终完成初步设计。

 

         业务逻辑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，所以说一个系统来说，业务逻辑是无处不在的。View上的是显示逻辑，Controller上是流程控制逻辑)，Model上简直就是“逻辑大本营”了。   

 

     使用 MVC 框架时我们要将“经常变化”的业务规则（位于Controller）和相对稳定的业务逻辑（位于Model）分离开，同时在Model层采用接口方式实现，以此来应对将来不断变化的业务需求。

    

 

           上文就已经简要说明了MVC中三部分的职责分配，但现在还有好多人简单的认为，C层就是简单调用M层，返回结果即可。若这样想、这样做的话，那么的确如上所说，就没有发挥出MVC的优势。势必将使的V层中代码混乱，逻辑不清，代码的重用性也不好等等一些弊端就出现了。其实学习这类抽象的理论，我们需要的是大胆的尝试和反复，不要怕，更不要像我身边的人，因为怕错，恶性循环，根本不知道该如何去做。要做好MVC，就按照自己的思路、和对它的理解，走通一条线（做一个功能的实现，比如登录功能），先不要管每层之间的职责有没有错误，先走出第一步也是很重要的。畏惧不前，不可要。

    

        

          我的一些开发感受，就是真切的体会分层之后系统的扩展性和可维护性的一种突变，通过处理YH项目的后期维护、新版本开发，对那些有关MVC好处的概念性东西有了进一步的理解。比如我要做更新，只需要将更新后的dll作为系统的一小部分进行升级即可，而不用大费周章的去动辄全身的改动。总结出来，就是解耦、真正在一定程度上进行了解耦就能放开手脚来做事。当然了，这里边修改代码还有着相当高深的技巧。我会整理一部分分享给大家的。http://blog.csdn.net/lfsfxy9/archive/2011/03/14/6249265.aspx