(转)浅析三层架构与MVC模式的区别

MVC模式介绍:

MVC全名是Model ViewController,是模型(model)-视图(view)-控制器(controller)的缩写,一种软件设计典范,用于组织代码用一种业务逻辑和数据显示分离的方法,这个方法的假设前提是如果业务逻辑被聚集到一个部件里面,而且界面和用户围绕数据的交互能被改进和个性化定制而不需要重新编写业务逻辑MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

MVC是表现层的架构,MVC的Model实际上是View Model,即供View进行展示的数据。 View Model不包含业务逻辑,也不包含数据读取。
而在N层架构中,一般还会有一个Model层,用来与数据库的表相对应,也就是所谓ORM中的O。这个Model可能是POCO,也可能是包含一些验证逻辑的实体类,一般也不包含数据读取。进行数据读取的是数据访问层。而作为UI层的MVC一般不直接操作数据访问层,中间会有一个业务逻辑层封装业务逻辑、调用数据访问层。UI层(Controller)通过业务逻辑层来得到数据(Model),并进行封装(View Model),然后选择相应的View。

MVC有三种角色:

Model:用来储存数据的组件(与领域模型概念不同,两者会相互交叉)

View:从Model中获取数据进行内容展示的组件。同样的Model在不同的View下可展示不同的效果。获取Model的状态,而不对其进行操作。

Controller:接受并处理用户指令(操作Model(业务)),选择一个View进行操作。

MVC主要用于表现层,3层主要用于体系架构,3层一般是表现层、中间层、数据层,其中表现层又可以分成M、V、C,(Model View Controller)模型-视图-控制器。

MVC模式是一种复合设计模式,一种在特定场合用于解决某种实际问题来得出的可以反复实践的解决方案。巧合的是他也有三个事物组成,于是乎人们就有了一种想当然的对应关系:展示层-View;业务逻辑层-Control;持久层-Model。首先MVC中的三个事物之间并不存在明显的层次结构,没有明显的向下依赖关系,相反的,View和Model往往是比较独立的,而Control是连接两者的桥梁,他们更像是横向的切分。这样一来就出现一个结果,MVC中每个块都是可以独立测试的,而三层结构中,上层模块的运行测试势必要提供下层代码或者提供相同接口的桩。相对来说,MVC复杂得多,但是结构更清晰,耦合性更低。

另外,MVC中每一块内部特别是Model内部经常被设计为多层的。在我认为的一个良好的MVC模式构建的结构中,Control是核心,小且较为稳定的,可以作为一个核心框架来提供,有扩展点,但基本上可以简单配置不需要任何代码就可以运行。而View则可能是一套或多种可选择的视图引擎,决定了软件展示给用户的界面,使用时的主要工作量在于扩展点以及根据需要而数量不同的视图模板。Model则是业务提供者,决定了软件提供的功能,其内部可能是一些普通的类或者是实现了某些接口的类,在这一块当中可能根据业务的不同而色彩缤纷,对于复杂的软件可能会分成很多层,如业务逻辑层、业务提供层、系统提供层、数据提供层、数据访问层等。

列举生活中的实例具体说明MVC

比喻MVC的例子是小时候玩的那种卡带式游戏机,Control是主机,一般来说我买一个主机就行了,只要他不坏,他就能一直让我玩这一类的游戏。View则是电视机和游戏手柄,电视机可以独立工作,他不管输入的是电视信号、影碟机信号还是游戏机信号,他只管显示,而且他决定了我们看到的效果是怎么样的,如果我想要个尺寸更大的或者彩色的显示效果,我只需要买个相应的电视机就行了,手柄也是可以换的,遥杆还是带震动的。Model则是游戏卡带,他决定了我玩的是什么游戏,是魂斗罗还是超级玛莉,而且游戏机主机和电视机生产厂家永远也不知道在上面有可能会运行什么样的游戏。卡带中可能会有游戏代码和存储单元,都根据游戏的需要而设计。

有朋友提到游戏主机提供的卡带插槽的接口,在设计中,有时也由Control提供一组接口,以用于Model或View的实现,这样就形成了依赖。一般来说这样设计也没有太大的问题,只是会提高模块间的耦合度,也会带来一些侵入性。为了更完美,可以不用接口来提供契约,可以用配置信息(或称元数据信息)+反射来提供契约,那么这个类接口就可以退化到只要符合CLS就可以了,也就是普通的类,就像现在的计算机接口广泛采用USB,无论是U盘、打印机、扫描仪或者是加密狗,他们都是普通的USB设备而已。

提到USB有一个题外话,模块的可插拔性设计甚至是热插拔设计,系统可以在不停止运行的情况下动态的挂载或移除模块,动态挂载模块需要系统能够自动发现新模块并根据自描述的信息进行自动配置,移除可能情况更复杂一点,需要"安全删除硬件"类似的功能。

在设计广泛重用的框架时会考虑多种情况以达到更大的适应性,一般项目中应用MVC模式可以较为随意。

下图是MVC组件类型的关系和功能图:

介绍完三层架构和MVC模式后,接下来回归主题,开始介绍二者的区别:

MVC(模型Model-视图View-控制器Controller)是一种设计模式,我们可以用它来创建在域对象和UI表示层对象之间的区分。

同样是架构级别的,相同的地方在于他们都有一个表示层,但是他们不同的地方在于其他的两个层。

在三层架构中没有定义Controller的概念。这是我认为最不同的地方。而MVC也没有把业务的逻辑访问看成两个层,这是采用三层架构或MVC搭建程序最主要的区别。当然了。在三层中也提到了Model,但是三层架构中Model的概念与MVC中Model的概念是不一样的,“三层”中典型的Model层是已实体类构成的,而MVC里,则是由业务逻辑与访问数据组成的。

三层架构和MVC是有明显区别的,MVC应该是展现模式(三个加起来以后才是三层架构中的UI层)
三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。
MVC是 Model-View-Controller,严格说这三个加起来以后才是三层架构中的UI层,也就是说,MVC把三层架构中的UI层再度进行了分化,分成了控制器、视图、实体三个部分,控制器完成页面逻辑,通过实体来与界面层完成通话;而C层直接与三层中的BLL进行对话。
MVC可以是三层中的一个表现层框架,属于表现层。三层和MVC可以共存。三层是基于业务逻辑来分的,而MVC是基于页面来分的。

MVC和三层之间的关系,见下图:

以上是我对三层架构与MVC模式的区别的简单介绍,如有问题,还请批评指教。

原文地址:http://blog.csdn.net/xjc1278003262/article/details/8870325

时间: 08-13

(转)浅析三层架构与MVC模式的区别的相关文章

软件三层架构和MVC模式的区别

刚开始学习MVC模式的时候,很容易将两个混为一谈,觉得两者一个是中文描述,一个是英文描述(哈哈,很奇怪当时的想法),当深入了解后,发现根本不是一回事啊,遂将两者做一下总结: 1. 从概念上来说: 三层架构是一个分层式的软件体系架构设计,适用于任何一个项目.而MVC是一种设计模式,它是根据项目的具体需求来决定是否使用这个设计模式 .从一个项目开始,首先需要进行架构设计,一般采用分层式的架构设计,即三层架构.在确定了架构设计之后,会根据具体的需求去考虑是否需要应用设计模式,比如说MVC模式,抽象工厂

三层架构和MVC模式

1.三层架构 三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI).业务逻辑层(BLL).数据访问层(DAL).区分层次的目的即为了"高内聚,低耦合"的思想. 1.表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得. 2.业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理. 3.数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添.删除.修改.更新.

java 三层架构与mvc模式的解释

三层架构是一种架构模式.分为: 持久层:完成内存数据和磁盘数据的转换,采用Dao模式,建立实体和数据库映射. 表--类 列--(数据库)属性 (ORM对象和关系的映射),主要目的是完成对象数据和关系数据转换 业务层:主要完成业务处理操作,采用事务脚本模式,将一个业务中所有的操作封装成一个方法,保证该方法中,所有的数据库操作,同时成功或者同时失败. 表现层:完成数据的展示和流程的控制,采用 MVC模式. 三层架构与MVC的关系: 表现层 ———–>mvc框架 业务层 ———–>service层

三层架构与MVC之间的区别

文章转发自:http://www.admin10000.com/document/535.html 我们平时总是将三层架构与MVC混为一谈,殊不知它俩并不是一个概念.下面我来为大家揭晓我所知道的一些真相. 首先,它俩根本不是一个概念. 三层架构是一个分层式的软件体系架构设计,它可适用于任何一个项目. MVC是一个设计模式,它是根据项目的具体需求来决定是否适用于该项目. 那么架构跟设计模式有什么区别呢? 我们从接手一个项目开始,首先,我们需要进行架构设计,一般我们采用的就是分层式的架构设计,即我们

[转]三层架构与MVC之间的区别

我们平时总是将三层架构与MVC混为一谈,殊不知它俩并不是一个概念.下面我来为大家揭晓我所知道的一些真相. 首先,它俩根本不是一个概念. 三层架构是一个分层式的软件体系架构设计,它可适用于任何一个项目. MVC是一个设计模式,它是根据项目的具体需求来决定是否适用于该项目. 那么架构跟设计模式有什么区别呢? 我们从接手一个项目开始,首先,我们需要进行架构设计,一般我们采用的就是分层式的架构设计,即我们的三层架构. 然后,在确定了架构以后,我们再根据项目的具体需求去考虑是否需要应用一些设计模式,比如是

三层架构和MVC

注:本文章内所有内容都来自互联网,本人主要是起了一个收集的作用 http://www.cnblogs.com/zhhh/archive/2011/06/10/2077519.html 又看到有人在问三层架构和MVC的关系,感觉这种问题有点教条化了.因为它们都在逻辑上将应用程序划为三块,凑了一个数字3,就有人非要把它们联系到一起了. 这两个东西我接触有几年了,有一点体会,表达一下: 三层是三层,MVC是MVC,它们毫无关系的. 三层是从整个应用程序架构的角度来分的三层(如果程序需要,还可以分多层)

Web项目的三层架构和MVC架构异同

http://www.cnblogs.com/zhhh/archive/2011/06/10/2077519.html 又看到有人在问三层架构和MVC的关系,感觉这种问题有点教条化了.因为它们都在逻辑上将应用程序划为三块,凑了一个数字3,就有人非要把它们联系到一起了. 这两个东西我接触有几年了,有一点体会,表达一下: 三层是三层,MVC是MVC,它们毫无关系的. 三层是从整个应用程序架构的角度来分的三层(如果程序需要,还可以分多层). 三层是为了解决整个应用程序中各个业务操作过程中不同阶段的代码

三层架构和MVC模型的常识

一.三层架构: 1.表现层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得. 2.业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理. 3.数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添.删除.修改.查找等. 优点 1.开发人员可以只关注整个结构中的其中某一层: 2.可以很容易的用新的实现来替换原有层次的实现: 3.可以降低层与层之间的依赖: 4.有利于标准化: 5.利于各层逻辑的复用. 6.结构更加的明确 7.在

三层架构和 MVC的区别

三层架构和MVC是有明显区别的,MVC应该是展现模式(三个加起来以后才是三层架构中的UI层) 三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI).业务逻辑层(BLL).数据访问层(DAL).区分层次的目的即为了“高内聚,低耦合”的思想. MVC是 Model-View-Controller,严格说这三个加起来以后才是三层架构中的UI层,也就是说,MVC把三层架构中的UI层再度进行了分化,分成了控制器.视图.实体三个部分,控制器完成页面逻