Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1504034
  • 博文数量: 164
  • 博客积分: 2993
  • 博客等级: 少校
  • 技术积分: 1718
  • 用 户 组: 普通用户
  • 注册时间: 2011-06-24 11:42
文章分类

全部博文(164)

文章存档

2014年(1)

2013年(36)

2012年(90)

2011年(37)

分类: Python/Ruby

2012-07-25 09:16:51

MVC是一个架构,或者说是一个设计模式,它就是强制性使应用程序的输入,处理和输出分开。将一个应用程序分为三个部分:Model,View,Controller。
具体的话就是:
视图
  视图就是负责跟用户交互的界面。一般就是由HTML,css元素组成的界面,当然现在还有一些像js,ajax,flex一些也都属于视图层。在视图层里没有真正的处理发生,之负责数据输出,并允许用户操纵的方式。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。
模型
Model代表一些应用数据和业务逻辑(一般通过通过javaBean,EJB之间实现)在MVC的三个部件中,模型拥有最多的处理任务。例如它可能用象EJBs和javabean这样的构件对象来处理数据库。被模型返回的数据是中立的,就是说模型与数据格式无关,这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用,所以减少了代码的重复性。
控制器
  控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时,控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求,然后用确定用哪个视图来显示模型处理返回的数据。

这样强制性的分开之后会有很多的优点
第一个:分工明确:使用MVC可以把数据库开发,程序业务逻辑开发,页面开发分开,每一层都具有相同的特征,方便以后的代码维护。它使程序员(Java开发人员)集中精力于业务逻辑,界面程序员(HTML和JSP开发人员)集中精力于表现形式上。

第二个:就是松耦合,视图层和业务层分离,这样就允许更改视图层代码而不用重新编译模型和控制器代码,同样,一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离,所以很容易改变应用程序的数据层和业务规则。
这一点我感觉比较重要,像实际应用的时候,我们还会把model模块细分为:数据库抽象层,数据操作层,业务逻辑层。这些也都是出于一个送耦合的考虑,改动其中一部分,不会影响到另一部分。

第三个:重用性高。像多个视图能够共享一个模型,不论你视图层是用flash界面或是wap界面,用一个模型就能处理他们。将数据和业务规则从表示层分开,就可以最大化从用代码。

用简单的jsp servlet 和javabean来举个注册的例子来说的话:首先是视图层注册的jsp文件,用户填写完用户信息后,提交一个请求,这个请求同过配置文件找到相应的servlet,servlet就相当于控制器,根据不同的用户请求类型,进而调用不用的业务逻辑层进行处理。处理完成之后又将结构信息反馈给jsp文件也就是视图层文件。最最简单的mvc大体上就是这个流程了。

不过MVC也有一定的缺点
 MVC的缺点是由于它没有明确的定义,所以完全理解MVC并不是很容易。使用MVC需要精心的计划,由于它的内部原理比较复杂,所以需要花费一些时间去思考。
   你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序,同时由于模型和视图要严格的分离,这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试,你就可以毫无顾忌的重用它们了。
  根据开发者经验,由于开发者将一个应用程序分成了三个部件,所以使用MVC同时也意味着你将要管理比以前更多的文件,这一点是显而易见的。这样好像我们的工作量增加了,但是请记住这比起它所能带给我们的好处是不值一提。
  MVC并不适合小型甚至中等规模的应用程序,花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
   总之,不要为了MVC而MVC就行了。
阅读(4516) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~