本文共 1330 字,大约阅读时间需要 4 分钟。
话说N多年前,在一个叫SmartTalk的国度出现了一个叫MVC的家伙,后来流窜到了java国,在Java国里呼风唤雨(java的很多有界面的组件,比如swing都是采用MVC模式设计的)。
首先,此人长了三只手。一只叫Model,它负责业务领域状态的知识,一只叫View,负责业务领域的表示视图,一只叫Controller,负责控制用户输入的流和状态。当模型某一部分发生变化的时候,通常使用事件通知表单来通知视图。但是这个家伙在Web上操作的时候遇到了麻烦。因为Web的浏览器是没有状态的,所以模型没有办法通知视图发生变化,而必须通过用户发出另一次请求才能知道模型的改变。(以上内容源自《jakarta struts编程》一书)
在jsp2.0规范中,java的MVC不允许直接请求jsp页面而是需要通过Servlet来重定向,具体的效果先不说,起码倒是把Controller和View分开了,而且也统一了入口,都是从控制器进入的,那么控制器的职责也就很清晰了:
Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案:
1、开发人员可以只关注整个结构中的其中某一层; 2、可以很容易的用新的实现来替换原有层次的实现; 3、可以降低层与层之间的依赖; 4、有利于标准化; 5、利于各层逻辑的复用。概括来说,分层式设计可以达至如下目的:分散关注、松散耦合、逻辑复用、标准定义。
一个好的分层式结构,可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口,负责不同逻辑设计的开发人员就可以分散关注,齐头并进。例如UI人员只需考虑用户界面的体验与操作,领域的设计人员可以仅关注业务逻辑的设计,而数据库设计人员也不必为繁琐的用户交互而头疼了。每个开发人员的任务得到了确认,开发进度就可以迅速的提高。
松散耦合的好处是显而易见的。如果一个系统没有分层,那么各自的逻辑都紧紧纠缠在一起,彼此间相互依赖,谁都是不可替换的。一旦发生改变,则牵一发而动全身,对项目的影响极为严重。降低层与层间的依赖性,既可以良好地保证未来的可扩展,在复用性上也是优势明显。每个功能模块一旦定义好统一的接口,就可以被各个模块所调用,而不用为相同的功能进行重复地开发。
进行好的分层式结构设计,标准也是必不可少的。只有在一定程度的标准化基础上,这个系统才是可扩展的,可替换的。而层与层之间的通信也必然保证了接口的标准化。
转载地址:http://hgkgn.baihongyu.com/