从三层架构到MVC,MVP

从三层架构到MVC,MVP

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

     当然这种架构模式本身的一些问题也会在接下来的内容就加以介绍，另外就是如果大家有什么
不同观点的话，欢迎拍砖（只要不打脸就行，呵呵）。

         首先说三层架构，即：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。每一层都有自己的职责，完成不同的任务，尽量减少不同层之间的交流，所有内聚性得到了大大的降低。下面是我对百度百科中的图加工之后的，很形象的表达了三层之间的关系。它就像一个夹心饼干，最上层的饼干是一个外表，最下层的饼干起到了不可或缺的支撑作用，中间的奶油将上下层连接起来，完成它们的交互作用。

                                   

        那么三层的到底都是做什么的呢？

1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。

2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。

3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。

 

       三层是将简单的问题复杂化，使用三层做过项目的朋友都知道用三层架构的项目比不用三层的代码量更加庞大，那还为什么还要分层呢？

         那就说说三层的优点： 
1.解耦。上一层只依赖于下一层，如果测试下一层没有问题，那么问题就只可能出现在本层了。便于发现和改正BUG。 
2.简化复杂问题。就比如tcpip协议的四层模型或OSI七层模型，各层分工明确，将一个复杂问题简化了。
3.便于系统维护/升级。各层间通过接口解耦，接口与实现分离，从而可以非常方便的替换掉实现，或者升级实现等。 
4.逻辑复用。例如原来基于B/S开发的程序现在要改成C/S，那么只要业务层的接口没有改变，那么业务层和数据层都可以直接复用。在如，只要数据访问层接口不变，那么使用便可以有对不同数据库的实现。 
5.便于团队开发。只要各层接口在开发前规定好，那么各层可以独立开发，进化或维护。 
6.方便部署。将各层开发成组件，则可以独立部署。

        其实分层也不一定只是分三层，如果你愿意的话你可以分得更多，分层分得少得话就和不分一样了，分得多的话软件的复杂性相应的也会增加，对别人来说也就不好理解了，同样也就不容易维护了。容易维护的产品必定是容易理解的，维护只是一个附带的产物罢了。

 

        多分层说了这么多了，下面说说MVC吧。其实MVC和三层不是一种东西，很多朋友都将二者混在了一起，没有真正的弄清二者之间的区别，它们确实也非常的相似，但是不是一种东西，就像让你比较社会主义制度和欧洲联盟一样。

         MVC是"Model-View-Controller"的缩写，中文翻译为"模型-视图-控制器"。View就是界面视图，所以我们容易和三层架构相混淆。三层架构为了各司其责，每个人都只顾自己的那点事，不关心别人是怎样实现的，而它们之间相互联系的部分谁都不愿意干，所以在它们中间（UI层和BLL层之间）就应用到了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层采用接口方式实现，以此来应对将来不断变化的业务需求。

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