MVC与三层架构

MVC

MVC是一个设计模式，它强制性的使应用程序的输入、处理和输出分开。使MVC应用程序被分成三个核心部件，他们各自处理自己的任务。有人说MVC是观察者模式的一个变种。我感觉也不无道理。因为MVC的应用很广，上网查过资料，不仅仅web开发中广泛使用，swing也是基于MVC开发的一个GUI界面库。

MVC分为模型、视图、控制器。

模型：

模型部件保存由视图显示，由控制器控制数据；模型封装了问题的核心数据、逻辑和功能的计算关系，它独立于具体的界面表达和I/O操作。模型可细分为两个概念：系统的内部状态，能够改变状态的行为。模型与数据格式无关，这样一个模型能为多个视图提供数据。模型是你所有的商业逻辑的代码所在。

我们在实现模型时，把做什么（业务逻辑）和如何做（业务实体）分离，实现逻辑的复用。有了这样的模型，我们能够轻松实现以下功能：

实现一个模型的多个视图；

采用多个控制器；

当模型改变时，所有的视图将自动刷新；

所有的控制器将相互独立工作。

视图：

视图部分处理流程：首先，页面版定义了页面的布局；页面配置文件视图具体内容（用户部件）；然后，有页面策略类初始化并加载页面；每个用户部件根据它自己的配置进行初始化，加载校验器并设置参数，以及事件的委托等；用户提交后，通过了表示层的效验，用户部件把数据自动提交给业务实体即模型。

创建视图的方法：

表单和窗体的交互；

其他的表示技术（特定与应用程序的定制标记、有包含文件的页面组件、图片处理组件）

控制器：

应用程序的控制器集中从客户端接受请求（典型情况下是一个运行浏览器的用户），决定执行什么商业逻辑功能，然后将产生下一步用户界面的责任委派给一个适当的视图组件。它提供了一个控制和处理请求的集中入口点，负责接收、截取并处理用户请求；根据当前状态和业务操作的结果决定向客户端呈现的视图。集中与客户端接受请求，决定执行什么商业逻辑功能，然后产生下一步用户界面的责任委派给一个适当的view组件。可以使用控制器来连接不同的模型和视图去完成用户的需求，这样控制器可以为构造应用程序提供强有力的手段。控制器可以根据用户的需求选择模型进行处理，然后选择视图将处理结果显示给用户。

控制器本身不输出任何东西和任何处理。它知识接受请求并决定调用哪个模型构件去处理请求，然后用确定那个视图来显示模型处理返回的数据。

创建控制器组件的方法：

为每一个可能接受的逻辑请求写一个Action类；

写一个定义类名和每个可能的映射相关的其他信息的actionmapping类；

写行为映射配置文件用来配置Controller Server；

给应用程序添加适当的struts组件。

那一个简单的登录模块做个例子：需求是你输入一个用户名、密码，如果输入的跟预先定义好的一样，那么就进入正确界面，如果不一样，就提示个错误信息“输入错误！”。

V 这个小小的模块中，起始的输入用户密码的页面跟经过效验后显示的页面就相当与view

C 而这里还需要一个Controller页面，就是用于接受输入进来的用户名密码，还有经过效验后返回的一个flg（此flg就是用户判断你输入是否正确，而跳到相应的页面的）

M 最后还缺一个Model，那么就是你那个用于效验的类了，他就是处理你输入的是否跟预先订好的一样不一样，之后返回一个flg。

这样就完全实现了逻辑跟页面的分离，我页面不管你咋整，反正我就一个显示，而Controller也不挂你Model判断对不对，反正我给你了用户名跟密码，你就得给我整回来一个flg来，而Model呢，则是反正你敢给我个用户名和密码，我就给你整过去个flg。

三层架构：

三层架构就是将整个业务应用划分为：表示层UI、业务逻辑层BLL、数据访问层DAL。区分层次的目的即是为了高内聚、低耦合的思想。

表示层UI：通俗将就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。

业务逻辑层BLL：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。如果说数据层是积木，那么逻辑基层就是对这些积木的搭建。系统主要功能和业务逻辑都在业务逻辑层进行处理。

数据访问层DAL：该层所做事务直接操作数据库，针对数据的增添、删除、更新、查找等。

所谓的三层体系结构，实际是在客户端与数据库之间加入了一个中间层，也叫做组件层，即上面的业务逻辑层。三层体系的应用程序将业务规则、数据访问、合法性、效验等工作放到了中间层进行处理，通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，在经由中间层与数据库进行交互。

举个例子：

数据访问层从数据库中取出 -10摄氏度，业务层按照一定的逻辑翻译成-10摄氏度，表示层现实给用户“哎呀！好冷呀今天”。
层就是一个黑盒子，我们不用知道它内部怎么实现，只需要知道如何调用它就行了。每层只与上下相邻的两层打交道。当一层内部由于技术变迁发生变化时，只要接口不变，其他层不用做任何改变。分层之后灵活性提高，也便于团队分工开发。

MVC与三层架构的区别：

Model是MVC模型的灵魂，包含了三层架构里面的“实体规范层”、“行为规则层”、“数据访问层”；控制器用来手机view提供的用户数据，传递给Model，同时返回Model处理后，的数据给view。Model的设计可以参考三层架构的设计方法，将实体、行为规则（业务逻辑）和数据访问分开，在数据访问上应用orm框架。

MVC与三层架构同样是架构级别的，相同的地方在于他们都有一个表现层，但是他们不同的地方在于其他两层。

在三层架构中没有定义Controller的概念。而MVC也没有把业务逻辑访问分为两个层，这是采用三层架构或MVC搭建程序最主要的区别。

三层中也提到了Model，但是三层架构中Model与MVC中的Model的概念不同，“三层”中典型的Model层是以实体类构成的。而MVC里，则使由业务逻辑和访问数据组成的。

总结：

MVC的协作：存在单项引用，例如model不知道view和Controller的存在。view不知道Controller的存在。这就隔离了表现层和数据。iew和Controller是单向引用。而实际中view和Controller也是有数据交互的。

MVC重要的是分离：1、view和数据model的分离，使用不同的view对相同的数据进行展示；分离可视的组件，能够对model进行独立测试。因为分离了可是组件减少了外部依赖利于测试。（数据库也是一种外部组件）；2、view和表现逻辑（Controller）的分离，Controller是一个表现逻辑的组件，并非一个业务逻辑组件。MVC可以作为表现模式也可以作为建构模式，意味这Controller也可以是业务逻辑。分离逻辑和具体展示。能够对逻辑独立测试。

三层架构的分层模式是典型的上下关系，上层依赖与下层。但是MVC作为表现模式是不存在上下关系的，二十相互协作关系。即使将MVC当作架构模式，也不是分层模式。MVC和三层架构基本没有可比性，是应用于不同领域的技术。