三层架构将整个项目划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。
MVC :即Model(模型),View(视图),Controller(控制)。
我们通常所见到的MVC一般也都是在应用三层架构的基础上,即将Model层再进行分层。而如果Model不再进行划分的话,那么 使用MVC的意义也就不大了。
三层架构的目的着重点是“高内聚,低耦合”,即解耦。
MVC的目的则是实现Web系统的职能分工,即职责划分。 其实职责划分也是解耦,但是三层侧重的是整体的一个解耦,而MVC侧重的是web系统的解耦,即侧重jsp和Servlet的一个解耦。
我们一般是在考虑使用(也可以不使用)了三层架构的基础上再根据具体需求决定是否需要使用MVC,于是我们常说的MVC中总 是伴随着三层架构,所以大家总是会认为MVC就是三层架构,三层架构就是MVC,殊不知,它们二者是一起出现的
三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI/web层)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。
1、表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得;操作界面———搭好的积木
2、业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。具体问题,具体分析——搭积木的方式。
3、数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找等——取出或者放回这些积木的动作。
- 耦合性:也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密,其耦合性就越强,模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。
- 内聚性:又称块内联系。指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素(语名之间、程序段之间)联系的越紧密,则它的内聚性就越高。
流程:根据表现层,设计业务逻辑层——>搭建数据访问层
表现层{
业务逻辑层{
数据访问层{
数据库
}
}
}
从最内层开始设计并实现。
MVC模式:MVC 是 Model-View-Controller 的简称,即模型-视图-控制器。它属于设计模式的范畴,就如同其他设计模式一样,模式的出现就是为了对某种功能的优化,而MVC模式可以看做是对三层架构中表现层的一种细分优化。
在三层中也提到了Model,但是三层架构中Model的概念与MVC中Model的概念是不一样的,“三层”中典型的Model层是以实体类构成的,而MVC里,则是由业务逻辑与访问数据组成的。
三层是从整个应用程序架构的角度来分的三层(如果程序需要,还可以分多层)。
三层是为了解决整个应用程序中各个业务操作过程中不同阶段的代码封装的问题,为了使程序员更加专注的处理某阶段的业务逻辑。
比如将数据库操作代码封装到一层中,提供一些方法根据参数直接返回用户需要的相应数据,这样在处理具体的业务逻辑的时候,就不用关心数据的存储问题了。
之所以说MVC和三层毫无关系,是因为它们二者使用范围不同:三层可以应用于任何语言、任何技术的应用程序;而MVC只是为了解决BS应用程序视图层各部分的耦合关系。它们互不冲突,可以同时存在,也可根据情况使用其中一种。
如果硬要给他们对应的话,那么三层架构中的UI对应MVC中的view(jsp),都是用于显示以及获取界面的数据;三层架构中的BLL层和DAL层对应MVC中的Model(javabean)层都是用于处理上层传递来的数据以及从数据库获取的数据的;MVC中的Controller(Servlet)最多算是三层架构中的UI的一部分,也就我们常说的是Servlet。
各模块解析
各模块定义
模型(Model):封装的是数据源和所有基于对这些数据的操作。在一个组件中,Model往往表示组件的状态和操作状态的方法。
视图(View):封装的是对数据源Model的一种显示。一个模型可以由多个视图,而一个视图理论上也可以与不同的模型关联起来。
控制器(Control):封装的是外界作用于模型的操作。通常,这些操作会转发到模型上,并调用模型中相应的一个或者多个方法。一般Controller在Model和View之间起到了沟通的作用,处理用户在View上的输入,并转发给Model。这样Model和View两者之间可以做到松散耦合,甚至可以彼此不知道对方,而由Controller连接起这两个部分。
各模块联系 !