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、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。