MVC分层结构的优缺点

什么是MVC?

      话说N多年前，在一个叫SmartTalk的国度出现了一个叫MVC的家伙，后来流窜到了java国，在Java国里呼风唤雨（java的很多有界面的组件，比如swing都是采用MVC模式设计的）。


这个MVC是个什么样的家伙？
     首先，此人长了三只手。一只叫Model，它负责业务领域状态的知识，一只叫View，负责业务领域的表示视图，一只叫Controller，负责控制用户输入的流和状态。当模型某一部分发生变化的时候，通常使用事件通知表单来通知视图。但是这个家伙在Web上操作的时候遇到了麻烦。因为Web的浏览器是没有状态的，所以模型没有办法通知视图发生变化，而必须通过用户发出另一次请求才能知道模型的改变。（以上内容源自《jakarta struts编程》一书）

    

      在jsp2.0规范中，java的MVC不允许直接请求jsp页面而是需要通过Servlet来重定向，具体的效果先不说，起码倒是把Controller和View分开了，而且也统一了入口，都是从控制器进入的，那么控制器的职责也就很清晰了：

拦截http请求
将请求转换成要执行的具体业务逻辑的操作
判断调用业务操作还是委托给处理程序
帮组用户选择要显示给客户端的下一个视图
将视图返回给客户端
分层式结构究竟其优势何在？Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案：
      1、开发人员可以只关注整个结构中的其中某一层；
      2、可以很容易的用新的实现来替换原有层次的实现；
      3、可以降低层与层之间的依赖；
      4、有利于标准化；
      5、利于各层逻辑的复用。

      概括来说，分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。

    

      一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。例如UI人员只需考虑用户界面的体验与操作，领域的设计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认，开发进度就可以迅速的提高。

      松散耦合的好处是显而易见的。如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。降低层与层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。每个功能模块一旦定义好统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。

      进行好的分层式结构设计，标准也是必不可少的。只有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必然保证了接口的标准化。

      “金无足赤，人无完人”，分层式结构也不可避免具有一些缺陷：
      1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
      2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码