《三层架构和mvc资料整合》由会员分享，可在线阅读，更多相关《三层架构和mvc资料整合（16页珍藏版）》请在金锄头文库上搜索。
1、WEB三层架构与MVC收藏而我发此文的目的有二：一者，让初学者能够听到一家之言，是为解惑；二者，更希望抛砖引玉，得到专家的批判。许多学生经常问我，MVC到底和WEB三层架构有啥关系？开始时，我也只能给他们一些模糊的回答。时间长了，自己的良心开始受到谴责。对于一个程序员来说，这个问题显得挺学究。我在跟自己的许多程序员朋友以及同行（Java讲师）都对MVC和WEB三层架构的关系做了探讨。现在可以说对WEB三层架构和MVC之间的关系理出了头绪。此可谓教学相长。先说说Web三层架构这个古老话题。地球人都知道web三层架构是指：* 用户接口层（UlLayer）业务逻辑层（BussinessLayer）持
2、久化层关于业务逻辑和用户接口在早期的web开发中，因为业务比较简单，并没有这三层的划分。用户数据的呈现及输入的接收、封装、验证、处理、以及对数据库的操作，都放在jsp页面中。这时的开发，好比盘古尚未开天辟地，整个web开发就是一片混沌”随着业务越来越复杂，人们开始考虑更好的利用OOP这把利刃来解决问题。于是有人发现把业务逻辑抽取出来并形成与显示和持久化无关的一层，能够让业务逻辑清晰，产品更便于维护。这就是SUN当初倡导的JSPModel1开发方式。关于持久化JSPM1开发方式中，并没有对数据如何持久化给出建议。在许多公司中，它们的产品是以数据库为中心进行架构和设计的。在他们的产品里，虽然也有D
3、AO层，但是职责不清。为什么这么说呢，因为我发现在许多人眼里，DAO层的指责很简单一一增删改查。但我认为，这样理解实际上是本末倒置了。对于简单数据的管理来说，这样理解无可厚非。但随着业务逻辑变得日益复杂。我们实在是被复杂的对象关系搞头疼了，如果这时我们还要考虑如何把数据存储起来（通常的情况下是存到关系型数据库中），我们开始抱怨自己软件的架构太恶心，一团糟。面向对象设计思想教会我们一一如果我们不想做这件事，就交给别人做吧！这时聪明的架构师们提出了一个概念一一持久化。如果我们在自己的应用中添加一个新的层专门负责对象状态的持久化保存及同步，那不就可以全心全意的搞对象”了吗？持久化概念的产生，代表着我
4、们对关系型数据库的依赖降低了。因此甚至有人推断一一数据库已死。同时，关系型数据库这个新的概念也不断形成，并演化成理论，又由理论衍生出产品。因此一个意识良好的程序员，至少应该认同，持久化并不是产品中最重要的环节一一最重要的环节是清晰正确的业务逻辑。灰色地带是的，从理论上看，web三层架构很美了。但在实际开发产品的时候，我们发现了很多问题。主要问题就是用UI层和业务层之间有许多灰色地带。这些灰色地带业务逻辑层不想管,UI层也不想管。让我们举一些例子：例子1，难以管理的页面跳转关系1，沖11丄*VrfhiFWtoirMrYirtkJn上图是我在讲JSP课程时，一个简单案例的页面跳转关系图。这是一个十
5、分简单的例子，但页面跳转关系已经挺复杂了。试想，如果你正在做一个有上百张表，十几个核心模块，几百个页面的产品时，这张图将变得多么复杂！而问题是，这些页面跳转关系分散在JSP和Servlet中，非常难以管理。例子2，表单数据的验证及封装：假设我们正在做一个简单的表单提交，我们希望对用户数据的数据进行验证和封装，最终交给业务逻辑层一个实体对象。从三层架构分析，我们想要做的事情是这样的：但是该把验证和封装数据的工作交给谁来做呢？UI层还是业务逻辑层？都不太合适!例子3，国际化：如果我们想为不同国家和地区的人提供不同的语言，无疑需要国际化的支持。那么，我们需要在JSP页面上根据用户的配置或请求信息判断
6、应该为该用户呈现哪国文字。而这些判断和显示的逻辑应该划分到业务逻辑层还是UI层呢？用MVC的思路解决问题对于纠缠不清的问题，我们总要想办法将其分解。MVC是一种设计思想。这种思想强调实现模型(Model)、视图(View)和控制器的分离。这种思想是如何作用于web的呢？实际上，我们在web开发中引入MVC思想，想要达到的目的是：实现UI层和业务逻辑层分离一-控制器是为了实现上述目的而存在的！在解决了持久化的问题后，我们发现，我们的所说的业务逻辑层和MVC中的Model指的是一回事，我们所说的UI层和MVC中的View是一回事。MVC提供了让模型和视图相分离的思路一一引入控制器。我们把页面跳转关
7、系管理、表单数据的封装及验证、国际化等任务交给控制器处理。因此，也不难理解为什么流行的MVC框架都具有管理页面跳转关系、表单数据的封装及验证、国际化等特性。总结在Javaweb开发中，MVC框架充当了UI层和业务逻辑层的适配器的作用。MVC框架实现了UI层和业务逻辑层最大程度的分离。使用mvc的好处，MVC使用规则java三层架构设计思想java开发web应用MVC使用规则为了提供可重用的设计及代码，M-V-C之间的交互应该很好地定义，以及它们相互间地依赖关系要尽量最小。使用MVC模式的其中一个目的就是，使一个单一的模型能与多个视图及控制器联合起来。MVC模型保证了视图能与模型同步。当控制器从
8、用户输入中接受到一个有效的命令后，它将调用模型上的相应方法。模型将确认该操作是否与当前的状态一致，然后再执行它，并相应地修改视图的状态。而视图，作为一个观察者，将根据得到的模型状态改变来更新它的显示。依赖关系保持最小为了使一个模型能在多个视图及控制器中使用，它们之间的依赖关系必须保持最小。要做到这些，必须遵守一下规则（如图10-03）：注意：A依赖于B,表示A的代码中需要与B相关的信息，如调用B的方法或使用B的属性。1、模型必须与视图及控制器没有任何依赖关系。2、视图依赖于与它相关的模型，它必须知道模型状态结构，这样才能把模型显示出来。3、视图不能依赖与控制器，这样的话，几个不同的控制器可以关
9、联相同视图。4、控制器依赖于相关的模型及视图，模型定义了控制器能调用的方法，而视图定义上下关系，通过它控制器可以解释用户输入信息。这使得控制器能紧紧地跟视图联系在一起。图10-03MVC模式中允许的依赖关系交互必须保持最小另外一个需要使用多视图及多控制器的前提条件就是保存最小的交互。特别是，控制器一定不要直接影响与它相关联的视图的显示。而是在用户输入产生的影响在视图中可见之前，控制器必须与模型进行一个完整的往返交互，这样能保证一个状态修改能更新所有的视图，以及视图能保持与模型同步。使用单一控制器的实现通常会违反这种规则，因为一些不够严谨的思维：“我已经知道这个状态修改要发生，所以不需要模型来告
10、诉我这个但这是错的，原因有三个：1、模型可能因为某些原因否决该操作，然后这个操作就不会发生了。2、其他控制器可能同时调用了该模型的操作，有些操作可能也会影响视图的显示，或者使操作不合法。3、另外，将来使用其他控制器来扩展这个实现也是可能的。MVC模式是Model-View-Controller的缩写，中文翻译为模式-视图-控制器。MVC应用程序总是由这三个部分组成。Event（事件）导致Controller改变Model或View，或者同时改变两者。只要Controller改变了Models的数据或者属性，所有依赖的View都会自动更新。类似的，只要Controller改变了View，View
11、会从潜在的Model中获取数据来刷新自己。MVC模式最早是smalltalk语言研究团提出的，应用于用户交互应用程序中。smalltalk语言和java语言有很多相似性,都是面向对象语言，很自然的SUN在petstore（宠物店）事例应用程序中就推荐MVC模式作为开发Web应用的架构模式。MVC模式是一种架构模式，其实需要其他模式协作完成。在J2EE模式目录中，通常采用servicetoworker模式实现，而servicetoworker模式可由集中控制器模式，派遣器模式和PageHelper模式组成。而Struts只实现了MVC的View和Controller两个部分，Model部分需要开
12、发者自己来实现，Struts提供了抽象类Action使开发者能将Model应用于Struts框架中。MVC模式是一个复杂的架构模式，其实现也显得非常复杂。但是，我们已经终结出了很多可靠的设计模式，多种设计模式结合在一起，使MVC模式的实现变得相对简单易行。Views可以看作一棵树，显然可以用CompositePattern来实现。Views和Models之间的关系可以用ObserverPattern体现。Controller控制Views的显示，可以用StrategyPattern实现。Model通常是一个调停者，可采用MediatorPattern来实现。现在让我们来了解一下MVC三个部分在
13、J2EE架构中处于什么位置，这样有助于我们理解MVC模式的实现。MVC与J2EE架构的对应关系是：View处于WebTier或者说是ClientTier，通常是JSP/Servlet，即页面显示部分。Controller也处于WebTier，通常用Servlet来实现，即页面显示的逻辑部分实现。Model处于MiddleTier，通常用服务端的javaBean或者EJB实现，即业务逻辑部分的实现。一、MVC设计思想MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层模型层
14、、视图层、控制层。视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面,但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。模型(Model):就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数
15、据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。控制（Controller）可以理解为从用户接收请求,将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数
