MVC

MVC 把用户界面交互拆分到不同的三种角色中.
Model View Controller
之所以这样做的原因:1,你可能要使用数个不同的用户界面来表现相同的业务逻辑，如果同时承担两种责任，用户界面会变得过分复杂
                   2，与GUI隔离之后，domain Objects的维护和演化更容易，甚至可以让不同的开发者负责不同部分的开发.
用过MVC后，替换视图才成为可能，如果没有用MVC则没有这种可能.

Web开发的挑战
   1.Web接口经常变化. 修改页面显示代码，无需修改业务对象甚至于Web 层控制代码.
   2.Web 接口牵涉到复杂的标签.
   3.Web 接口与GUI  有极大的差别.
   4.HTTP请求只能携带字符串参数。
   5.Web  接口使确认用户输入变得困难，因为我们对客户浏览器只有有限的控制权.GUI则有完全的控制权.
   6.HTML只提供UI控制的有限选择.
   7.保证web站点看起来正确并在所有常见浏览器中都正确工作会很困难.
   8.存在许多效率考虑因素.
   9.Web  接口的测试相当困难.
服务器小程序和视图技术都是建立可维护J2EEWEB应用所必需的。服务器小程序和助手类应该用来处理控制流和启动业务操作；JSP只应该用来再现内容.

MVC流程(Front Controller流程):
一条请求消息进入输入控制器，输入控制器从中取得信息，它随后把业务逻辑传送给一个合适的模型对象。这个模型对象和数据源交互，并且按照请求消息的要求进行处理，应答并收集信息，当做完这些后，它再把控制权交给输入控制器，输入控制器察看结果并且决定采用什么样的视图来显示应答消息。输入控制器不是直接传递给视图，通常，这是一个包括把数据放在某种HTTP会话对象中合适位置的过程，这个HTTP会话对象在输入控制器和视图之间共享.
  好处:1.首先也是最重要的使用模型-视图-控制器的理由是要保证模型和WEB表现层的完全分离，这使得修改表现层以及加入其它的表现层都会容易。
       2.同样把处理过程放到分离的事务脚本或分离的领域模型对象中也会使得它们容易测试。如果你正在使用服务器页面(JSP)作为视图，这一点很理要.
       3.增加代码的重用性,切换视图代码，理想状态可以不用动控制代码和模型代码.

WEB层的设计目标。  两个目标:1.可维护性,2.可扩展性. 也仍包括软件的设计目标.要重用性，可测试性.
  A:干净的WEB层把控制流和业务对象调用(Java对象处理)与表示(JSP页之类的视图构件处理)分隔开.(模块化思想)
  B:细薄WEB层。意味着除了用户动作中启动业务处理和显示结果所必需的Java代码之外,Web 层不应该再含有任何Java代码.这也意味着WEB层只应该含有与WEB特定相关的控制逻辑

(如选择数据应该被显示在里面的布局),不应该含有业务逻辑(如数据检索).

考虑MVC时，关注两个主要的分离:从模型中分离表现和从视图中分离控制器.
视图的考虑:富客户, WEB浏览器,远程API和命令行界面.甚至同一应用程序的几个不同点上有不同的用户界面.
模型中分离表现是必需的，因为两者的责任不同，视图中分离控制器在WEB应用中是分离的，在富客户应用中则并不需要进行分离.

业务逻辑束缚于WEB层的应用的坏处:
   1.可测试性.测试起来困难,业务逻辑依赖WEB环境.但事实上业务组件应该能被单独测试而不依赖环境.整体测试WEB接口来测试业务逻辑,这是相当困难的.
   2.可重用性.降低重用业务逻辑代码的可能性.Model View Controller ,Model封装业务逻辑代码，有重用性，理想情况下可以用不同的View来显示Model的结果.MVC 使这种可能变为现实.
   3.可扩展性.没有OO的设计，使得代码的可插入性为零.
在一个设计完善的J2EE 应用中,WEB层应该是一个以定义明确的业务接口为建立基础的细薄层.它应该只负责把用户动作转换成应用事件，以及把用户输入的结果处理成由WEB 接口的结果.

一个细薄的WEB层和一个干净的WEB层一样重要.  干净的Web层指Web层代码指模型与表示的分离. 细薄指Web层代码只应去调用业务代码而不是去实现业务代码,要把业务代码封装到后端业务对象中去.

MVC三者的职责.:
Controller 负责与业务对象交互，向业务对象传递必要的数据，然后获得业务对象计算的结果，包装为值对象，通过request对象(request.setAttribute()方法)传递到页面.包括必要的异常处理.
View负责显示由Controller发过来的值对象，包括必要的页面显示逻辑.
Model狭义说是值对象,广义指业务对象及业务对象计算的结果.

视图技术的三种选择:
1.转换视图 2.模板视图 3.两步视图
控制器
1.Front Controller 2.Page Controller.


Front Controller一般由两部分组成:一个Web处理程序和一个Command层次结构.
WEB处理程序是一个实际上接收来自Web服务器的POST或GET请求的对象。它从URL中得到信息，并且决定下一步的动作是什么，分发请求但不处理请求，请求委托给Command执行动

作.

Web处理程序可以动态或静态地决定运行哪一个Command,其中的静态行为包括解析URL并使用条件逻辑.
动态行为包括提取URL中的某个标准部分和用动态实例化去创建一个Command类.
  静态方法的好处.1,2,3.  1.简明清晰的逻辑.2.在调度时可以执行编译时错误检查.3.在分析URL的时候可以拥有更多的灵活性.
  动态方法的好处.允许你在不改动WEB处理程序的情况下增加新的Command.


MVC与Observer模式的关系. GUI的MVC是一种推模式,由模型对象生成事件去通知视图(监听器). Web层MVC是一种拉模式,由视图去获得模型数据,通过控制器做中间人.
MVC  实现方式.  Front Controller 模式,Page Controller模式.
MVC的任务.
不同的客户端:富客户端,Web 浏览器，远程API，命令行界面,PDA. 其中最重要的MVC的实现差别富客户端和Web前端的差别.在于视图和控制器的是否完全分离.
Web可选的视图:模板视图，转换视图，两步视图.