在说MVC和三层架构前,先看看什么是servlet
也就是说,servlet可以接收到客户端发送过来的请求,对请求进行处理后返回响应给客户端。
一个简单的项目其实有servlet已经是可以实现的了,但这样在项目变大时就会暴露许多弊端,最直观的就是造成 那些复杂的业务逻辑代码 还有 操作数据库部分的代码 都写在了同一个servlet里,导致servlet变得很复杂,在后期维护的时候会非常不方便,所以在写一个项目时,通常都会把这些代码提取出来,但光是提取出来放到一个文件夹里,也只会导致这个文件夹的文件很乱。
所以开发一个项目时,对代码进行分类整合是挺有必要的,那什么代码要放到什么类里,一个类又要放到哪个文件夹里呢?
这就需要一个模式去规范,MVC和三层架构就是两种用来进行规范的模式。
设计模式(Design Pattern)是前辈们对代码开发经验的总结,是一套被反复使用、多数人知道的、经过分类编目的、代码设计经验的总结。它不是语法规定,而是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。
说明:mvc设计模式(不属于23种设计模式)
这里说明一下,网上很多人对MVC是设计模式还是架构模式是有争议的,这里个人认为现在还没必要纠结这个,真想弄懂,可以等以后有能力有经验了,看官方的英文文档自行理解,毕竟看网上的其实也只是别人翻译过来的,每个人对这些名词的定义可能都会有差异,所以对这些概念的理解有差异也正常
Web MVC中的M(模型)-V(视图)-C(控制器)概念和标准MVC概念⼀样,我们再看⼀下Web MVC标准架构,如下图所示:
在标准MVC模式下,Model是可以直接把模型数据推给View的,
在Web MVC模式下,模型⽆法主动推数据给视图,如果⽤户想要视图更新,需要再发送⼀次请求(即请求-响应模型)。
M:(Model) 模型 :
应⽤程序的核⼼功能,管理这个模块中⽤的数据和值,
项目中一般负责处理业务逻辑和与数据库的交互;
V(View )视图:
视图提供模型的展示,管理模型如何显示给⽤户,它是应⽤程序的外观,
负责显示数据和提交数据;
C(Controller)控制器:
对⽤户的输⼊做出反应,管理⽤户和视图的交互,是连接模型和视图的枢纽。
负责接受用户发来的请求,并调用对应的Model,待Model处理完,根据其返回的数据选择对应的View进行展示。
bean是划分到Model里的,看看什么是JavaBean:
JavaBeans :是Java中⼀种特殊的类(换⾔之:JavaBean就是⼀个Java类).
⼀个Java类,满⾜以下要求,则可称为⼀个JavaBean
a. public修饰的类,提供public ⽆参构造⽅法
b. 所有属性都是private
c. 提供getter和setter⽅法
从使⽤层⾯来看,JavaBean分为2⼤类:
a. 封装业务逻辑的JavaBean(eg:LoginDao.java 封装了登录逻辑)
b.封装数据的JavaBean(实体类:eg:Student.java Vadio.java 。
往往对应于数据库中的⼀张表,即数据库中有个Student表,
项⽬中就有个Student.java类)通常:表名=类名,列名=属性名
JavaBean是⼀个可以重复使⽤的组件,通过编写⼀个组件来实现某种通⽤功能,“⼀次编写、任何地⽅执⾏、任何地⽅重⽤”。
MVC设计模式用一种业务逻辑、数据、界面显示分离的方法组织代码。一般项目中目录这样划分:
Controller在项目中就是servlet文件夹里了写的servlet
Model在项目中就是有关业务逻辑的和操作数据库部分的代码,写在service和dao文件夹里,还包括一个写着与数据库表相关的实体类的bean文件夹
servlet在接收到请求后,就会调用这些文件夹里对应的类和方法进行处理
View在项目中就是web文件夹下的jsp或者html页面
servlet选择要跳转的页面,并将接收到的数据传给该页面
页面对接收到的数据进行展示
架构模式,也叫架构风格,一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些呈现定义好的子系统,指定它们的责任,并给出把它们组织在一起的法则和指南。一个架构模式常常可以分解成很多个设计模式的联合使用。
三层架构 通常意义上的三层架构就是将整个业务应⽤划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL),各层之前用接口相互访问,并通过对象模型的实体类(Model)作为数据传递的载体,不同的对象模型的实体类一般对应于数据库的不同表,实体类的属性与数据库表的字段名一致。
区分层次的⽬的即为了“⾼内聚,低耦合”的思想。
表现层(UI):
通俗讲就是展现给⽤户的界⾯,即⽤户在使⽤⼀个系统的时候他的所⻅所得。
业务逻辑层(BLL): 针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。
数据访问层(DAL): 该层所做事务直接操作数据库,针对数据的增添、删除、修改、更新、查找 等。
表现层实现的代表作品是Struts,springmvc框架,
业务层实现的代表作品是Spring,
持久层实现的代表作品是Hibernate,mybatis。
层就相当于⼀个⿊盒⼦,我们不⽤知道它内部怎么实现,只需要知道如何去调⽤它就⾏了。每层只与上下相邻的两层打交道。当⼀层内部由于技术变迁发⽣变化时,只要接⼝不变,其他层不⽤做任何改变。 分层之后灵活性提⾼,也便于团队分⼯开发。
三层架构中有一个叫对象模型的实体类(Model)的东西,写在bean文件夹里,它不属于三层中任何一层,只是每一层都可以调用这些实体类,它相当于一个载体,用于数据的传输。
其实我个人感觉两者是两种不同的东西,是两种思想,是对一个问题的两种不同的解决方案,只是两种方案的侧重点不同这样。
比如上面提到的两种目录划分,其实目录文件夹都是一样的,但以不同的方式去划分,就可以说是基于不同的模式来规范的。
MVC和三层架构都是为了把项目规划好,对项目进行解耦,让不同的模块专注于不同的功能,哪个模块需要修改时,只需改动该模块的内容就行,以便更好的团队合作,高效开发以及后期维护。
非要说两者有什么联系的话,我认为是三层架构里有MVC的思想,但又不完全是,比如MVC里的View和Controller相当于三层架构中三层的表现层的拆分,而三层里的BLL和DAL又相当于把MVC的Model的拆分,也可以理解为两者的侧重点不一样,MVC侧重于页面,数据展现及其与后台程序的交互等,三层架构则更侧重于业务逻辑(毕竟一般情况下也是什么是重点才会进行拆分来详细说明,而不是重点的就会概括起来给个统称这样嘛,哈哈)
这里有一种说法,当做参考一下
MVC是Model-View-Controller,严格说这三个加起来以后才是三层架构中的UI层,也就是说,MVC把三层架构中的UI层再度进⾏了分化,分成了控制器、视图、实体三个部分,控制器完成⻚⾯逻辑,通过实体来与界⾯层完成通话;⽽C层直接与三层中的BLL进⾏对话。
MVC可以是三层中的⼀个表现层框架,属于表现层。三层和mvc可以共存。
三层是基于业务逻辑来分的,⽽MVC是基于⻚⾯来分的。
MVC主要⽤于表现层,三层主要⽤于体系架构,三层⼀般是表现层、中间层、数据层,其中表现层⼜可以分成M、V、C,(Model View Controller)模型-视图-控制器
MVC是表现模式(Presentation Pattern)
三层架构是典型的架构模式(Architecture Pattern)
三层架构的分层模式是典型的上下关系,上层依赖于下层。但MVC作为表现模式是不存在上下关系的,⽽是相互协作关系。即使将MVC当作架构模式,也不是分层模式。MVC和三层架构基本没有可⽐性,是应⽤于不同领域的技术。