从三层架构到MVC，MVP

从三层架构到MVC,MVP

      原本是不想跳出来充大头蒜的，但最近发现园子里关于MVC的文章和讨论之风越刮越烈，其中有
些朋友的观点并非我所欣赏和推荐的，同时最近也在忙着给公司里的同事作MVC方面的“扫盲工做”。
因此就搜集了一些你们接触MVC的过程当中常常出现的问题作了一下解释说明，但愿能与你们多多交流，
呵呵。

     固然这种架构模式自己的一些问题也会在接下来的内容就加以介绍，另外就是若是你们有什么
不一样观点的话，欢迎拍砖（只要不打脸就行，呵呵）。

    一.  MVC是谁提出的    
     模型－视图－控制器（MVC）是Xerox PARC在八十年代为编程语言Smalltalk－80发明的一种软件
设计模式，至今已被普遍使用。最近几年被推荐为Sun公司J2EE平台的设计模式，而且受到愈来愈多的
使用 ColdFusion 和 PHP 的开发者的欢迎。模型－视图－控制器模式是一个有用的工具箱，它有不少
好处，但也有一些缺点。

    二.  MVC是否适合进行大项目的开发
    MVC框架确定是适合于作大项目开发的，但并非说有了MVC框架咱们就能够开发大项目，听起来
有些绕，其实道理很简单，缘由就是人（开发者）。若是你是一个对MVC框架的设计理念有深刻研究
的人，那么你在使用MVC框架进行产品和项目开发的时候就会随时随地都要考虑一些问题：

    1.低耦合性（强调视图层和业务层分离）
    2.可测试性（这个很是重要）
    3.高重用性和可适用性
    4.有利于软件工程化管理等等。

    这里我很欣赏老赵的治学态度，由于在他的文章和代码中随时随地都在进行着思考，特别是其对
可测试性，单元测试（这里不是什么TDD）的思考，让我看起来有心灵相通的感受。由于这些问题都
是在作中型甚至大型项目中要认真思考的，决不是说微软给的例子就是咱们的惟一准则，一定里面有
对也有错，我相信在MVC面前，国内甚至微软内部的牛人都不是不少。

    说了这些，你们能够意识到了，若是在没有理解下面这张图以及对MVC的“所谓优势是从何处得
到的”有认识，而一上来就去拿MVC去开发大型项目的话，我想不只不能发挥asp.net MVC框架的估
势，相反会时时受制于里面的约束，配置和功能特性，最后感受还不如直接用asp.net webform开发
来的直接，不是吗？真要是到了这一境地，我想不只没法使用MVC进行大型目开发，就连中小企业应
用都应付不来。

         

   

     三.  能不能使用MVC架构进行Webform的开发    
     在园子里有人尝试使用ASP.NET MVC 框架来进行webform方式的开发，我我的是不欣赏这种作法
的，这就比如在使用LINQ的项目中又同时使用SQL语句同样“怪异”，这在代码的总体风格上会让人
产生迷惑，不是吗？固然老赵也在他的视频课程中提到在webform页面中使用一些MVC功能（好比：
ModelBinder等），但我想老赵的本意决不是让这种混合方式的开发大行其道，一定这是“非主流”，
因此孰轻孰重仍是要你们本身把握的。
   

     四. 传统的三（N）层架构与MVC，以及MVC与MVP关系    
     本文所说的三层架构指：表现层（显示层）， 业务逻辑层， 数据访问层（持久化）。若是你们
非要“生搬硬套”的把它与MVC扯上关系的话，那我就只能在这里"强扭这个瓜"了，即：

     三层架构中"表现层"的aspx页面对应MVC中的View（继承的类不同）
    
     三层架构中"表现层"的aspx.cs页面(类)对应MVC中的Controller,理解这一点并不难，你们想想
咱们之前写过的Redirect，固然它自己就是跳转了一些连接页面，而MVC中的Controller要作的更爽，
它控制并显示输出了一个视图。即然所起到的做用都是对业务流程和显示信息的控制，只不过是实现
手段不一样而已。

      三层架构中业务逻辑层和数据访问层对应MVC中的Model(一定View和Controller已找到“婆家”，
剩下的Model只能是业务业务层和数据访问层的了，呵呵)。但其实微软的一些MVC示例项目中对这个
问题理解的并非这样简单，这一点在我以前的关于两个MVC示例的思考(MVCStore和Oxite) 已阐述
过，就很少说了。  
    
     其实明白了这个关系，就能够尝试把之前的三层结构迁移到MVC框架下，固然在这个过程当中确定
会遇到这样或那样的问题，但原则就是把将MVC的优点发挥到极致，要否则还不如不作。

     说到这里，其实早在N年前就有人提出使用FrontController（前端控制器）来实现对HTTP页面请
求的路由跳转（包括数据的展示），说白了就是使用HttpHandler来进行页面请求的处理和数据绑定，
而不是彻底“期望”普通的页面访问重定向等。这样作的目的，就我而言与Routing中的Controller
和Action的出发点标是一致的，只不过Routing实现的更优雅同时也更底层一些。

     说完了三层架构，再看看MVC与MVP，其实在这以前咱们有必要看一下这张图:

 
         
     看完了上面的图，你们就会发现MVP与MVC最大的一个区别就是“Model与View层之间倒底该不应
通讯（甚至双向通讯，如图）。我想这也是目前作这两方面研究的”砖家“所互相争论的战场。一定各
有各的好处和因好处要付出的代价。起码在MVP模式下的Presenter要拥有“绝对权力”。若是没有它，
MODEL与View就是两个孤岛，尽管各有各的地盘（彻底解耦），但不会给企业带来什么有用的价值。
因此我这里有一个比喻来形容MVP中的：

     Presenter ----就是一个控制欲极强的女人，甚至就连“用什么姿式”，它都要管一管。
    
     固然日里万机操心多了就会让本身要作的事愈来愈多，最终它面临的就是该层代码日益庞杂，
且书写起来不太方便，一定就连事件绑定这类”“毛算皮的事都要归它管，累不累呀。最终咱们看到
MVP中的View就真的代码轻闲了很多（国企职工嘛），难怪说View只要从相应的IVIEW接口下实现相
应的属性和一些简单方法就完事了，而最终调用IVIEW接口下的那个视图实例则彻底交给了Presenter，
这让我想到了MVC中能够支持“自定义模版引擎（最终由MVC框架来控制使用系统仍是自定义的模版
引擎）”以及平时你们常挂在嘴边的换肤功能，想到这里多少还真有那么点意思了（精神层面上）。

     固然在微软内部对MVP的理解也有所不一样，以下图中所说的Supervising Controller模式和上面
你们看到的PassiveView.
 

     Supervising Controller模式其实很接近于MVC的那张图了，只是又提供了Presenter与View之间
的“双向通讯”。这种作法也是有不少不一样意见的，起码对那些支持“单向依赖”的开发者而言是“
嗤之以鼻”的。

     说到这里，表达一下个人观点，我是偏向于PassiveView的，虽然这种模式有些霸道，但一定是
让Model和View之间真正解耦，为开发者提供了最大的“控制成就感”，能够说想怎么控制视图就怎
么控制，但所以所形成的问题就是代码书写量和实现复杂性等问题了。

      

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

     另外这里向你们推荐一个不错的方法"Robustness"，有了它您就能够很容易的找出那些系统方法
要放在MODEL中，哪些该纳入控制逻辑中了，该方法我在两年前的一篇文章中提到过，你们感兴趣的
话能够看看这个连接, 采用[ICONIX] 方法实践BLOG设计之四 [健壮性分析] .
     其核心内容以下：   

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

   边界对象(boundary object)：
         参与者使用它来同系统交互，这一般包含窗口，屏幕，对话框和菜单。若是有GUI原型，
   将会知道许多主要的边界对象是什么。

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

  

      上面的三个对象分别对应Model, View, Controller.
     
      正如文中所说，该方法还提供了以下好处：    

   1.它帮助您确保用例文本的正确性，且没有指定不合理或不可能的行为 (基于要使用的一组对
     象)，从而提供了健康性检查。
   2.帮助确保用例考虑了全部必需的分支流程，从而提供了完整性和正确性检查。
   3.让您可以(持续)发现对象，由于在域建模期间可能会遗漏一些对象， 而这些对象在绘制时
     序图时不易被发现，而且极可能正是它致使没法绘制时序图。
   4.缩小分析和设计的鸿沟，从而最终完成初步设计(关于初步设计复核会在下一篇中介绍)。

 

      六.MVC与MVP是否能够同时出如今一个SLN甚至一个项目中   
      这一点我想谁说了都不算数，只有用户需求才是王道，用户使用在当前项目中实现某些特定
功能，而该功能偏偏是MVC或MVP的用武之地，那就一个字：“用”。

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

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

      好了，今天的内容就先到这里了。
   

      原文连接:http://www.cnblogs.com/daizhj/archive/2009/04/30/1447035.html

      做者: daizhj, 代震军