三层架构（DAL/BLL/UI）和MVC设计模式的关系

青旅半醒 2022-07-15 13:39 210阅读 0赞

首先,**MVC**和三层架构，是不一样的。

BLL 是业务逻辑层 Business Logic Layer

DAL 是数据访问层 Data Access Layer

ASP.NET的三层架构(DAL,BLL,UI)

图形表示三层结构. 其中web即为USL层

三层架构中，DAL(数据访问层)、BLL(业务逻辑层)、WEB层各司其职，意在职责分离。  
　　**MVC**是 Model-View-Controller，严格说这三个加起来以后才是三层架构中的WEB层，也就是说，**MVC**把三层架构中的WEB层再度进行了分化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。  
　　所以，**.net**的三层结构中，并没有action这个概念。  
　　**asp.net****mvc**是微软新发布的一种网站开发架构。为了解决传统**asp.net**开发中不能分离Model,View和Controller而设计的。  
　　普通的网站为了解决可移植，可维护，可扩展等问题，会把网站设计成三个独立的模块，Model负责数据库部分，View负责网页的界面，而Controller负责界面与数据的交互及业务逻辑，这样设计的网站如果想设计或者重新开发某一个模块对其他的模块是没有影响的。但是**asp.net**的页面后台代码与每个页面代码都是一一对应的，业务逻辑在某些情况下不可避免的被写到了与View关联的后台代码中。这样就不能保证View与Controller的分离，也就很难实现网站的重写和升级。  
　　而在**MVC**中页面代码并不是与后台代码一一对应，而是分别被存放成Controller和View两个部分，彻底的解决了，View和Controller不能独立的问题。从而改善网站的重写和升级过程。  
　　但是**MVC**也有其缺点，由于在页面代码中不再可以使用服务器控件，因此给某些**asp.net**服务器端控件的使用带来了麻烦，而且**MVC**也页面的设计工作带来了很多障碍。  
　　**ASP.NET****MVC**是微软在2009年4月份发布的一种新的网站开发架构，http://msdn.microsoft.com/en-us/library/dd394709.a spx，它是把传统意义上的**MVC**开发思想融合到了**ASP.NET**的开发当中。  
　　那么我也来讲讲我对这两者的理解吧。  
　　首先对这个题目，本身是存在问题的，"XX结构"与"XX模式"的区别？请问中国社会制度与美国人生活方式有什么区别？  
　　这两者本身讲的是不同方向与角度的问题，在实际应用中他们的确存在一些相似的特点，在很多**书籍**中也没有深入讲解，以致于造成困惑，为了更好的理解他们，姑且来说说区别吧。  
　　首先N层结构是一种软件抽象的层次结构，是对复杂软件的一种纵向切分，每一层次中完成同一类型的操作，以便将各种代码以其完成的使命作为依据来分割，以将低软件的复杂度，提高其可维护性。一般来说，层次之间是向下依赖的，下层代码未确定其接口（契约）前，上层代码是无法开发的，下层代码接口（契约）的变化将使上层的代码一起变化。三层结构是N层结构的一种，是人产在长时间使用中得出来的一种应用场合广泛的N层结构，被当作一种典型的软件层次结构而广为流传甚至写入教科书。  
　　**MVC**模式是一种复合设计模式，一种在特定场合用于解决某种实际问题来得出的可以反复实践的解决方案。巧合的是他也有三个事物组成，于是乎人们就有了一种想当然的对应关系：展示层-View；业务逻辑层-Control；持久层-Model。首先**MVC**中的三个事物之间并不存在明显的层次结构，没有明显的向下依赖关系，相反的，View和Model往往是比较独立的，而Control是连接两者的桥梁，他们更像是横向的切分。这样一来就出现一个结果，**MVC**中每个块都是可以独立测试的，而三层结构中，上层模块的运行测试势必要提供下层代码或者提供相同接口的桩。相对来说，**MVC**复杂得多，但是结构更清晰，耦合性更低。  
　　另外，**MVC**中每一块内部特别是Model内部经常被设计为多层的。在我认为的一个良好的**MVC**模式构建的结构中，Control是核心，小且较为稳定的，可以作为一个核心框架来提供，有扩展点，但基本上可以简单配置不需要任何代码就可以运行。而View则可能是一套或多种可选择的视图引擎，决定了软件展示给用于的界面，使用时的主要工作量在于扩展点以及根据需要而数量不同的视图模板。Model则是业务提供者，决定了软件提供的功能，其内部可能是一些普通的类或者是实现了某些接口的类，在这一块当中可能根据业务的不同而色彩缤纷，对于复杂的软件可能会分成很多层，如业务逻辑层、业务提供层、系统提供层、数据提供层、数据访问层等。  
　　我经常用于比喻**MVC**的例子是小时候玩的那种卡带式游戏机，Control是主机，一般来说我买一个主机就行了，只要他不坏，他就能一直让我玩这一类的游戏。View则是电视机和游戏手柄，电视机可以独立工作，他不管输入的是电视信号、影碟机信号还是游戏机信号，他只管显示，而且他决定了我们看到的效果是怎么样的，如果我想要个尺寸更大的或者彩色的显示效果，我只需要买个相应的电视机就行了，手柄也是可以换的，要遥杆还是带震动的。Model则是游戏卡带，他绝定了我玩的是什么游戏，是魂斗罗还是超级玛莉，而且游戏机主机和电视机生产厂家永远也不知道在上面有可能会运行什么样的游戏。卡带中可能会有游戏代码和存储单元，都根据游戏的需要而设计。  
　　有朋友提到游戏主机提供的卡带插槽的接口，在设计中，有时也由Control提供一组接口，以用于Model或View的实现，这样就形成了依赖。一般来说这样设计也没有太大的问题，只是会提高模块间的耦合度，也会带来一些侵入性。为了更完美，可以不用接口来提供契约，可以用配置信息（或称元数据信息）+反射来提供契约，那么这个类接口就可以退化到只要符合CLS就可以了，也就是普通的类，就像现在的计算机接口广泛采用USB，无论是U盘、打印机、扫描仪或者是加密狗，他们都是普通的USB设备而已。  
　　提到USB有一个题外话，模块的可插拔性设计甚至是热插拔设计，系统可以在不停止运行的情况下动态的挂载或移除模块，动态挂载模块需要系统能够自动发现新模块并根据自描述的信息进行自动配置，移除可能情况更复杂一点，需要"安全删除硬件"类似的功能。

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

所以呢，你可以完全不用ORM那套东西，直接用代码生成器，生成三层架构，把WEB层换成mvc模式的，like this:

![1355062119_9401.jpg][]

三层架构的有关问题~~~~

一、三层体系架构  
　　1.表示层(USL)：主要表示WEB方式，也可以表示成WINFORM方式。如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。  
　　2.业务逻辑层(BLL)：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理。如果说数据层是积木，那逻辑层就是对这些积木的搭建。  
　　3.数据访问层(DAL)：主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层

提供数据服务.

二、具体区分  
　　1.表示层：主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。  
　　2.业务逻辑层：主要负责对数据层的操作，也就是说把一些数据层的操作进行组合。  
　　3.数据访问层：主要看你的数据层里面有没有包含逻辑处理，实际上他的各个函数主要完成各个对数据文件的操作，而不必管其他操作。

三、总结  
　　三层结构是一种严格分层方法，即数据访问层(DAL)只能被业务逻辑层(BLL)访问，业务逻辑层只能被表示层(USL)访问，用户通过表示层将请求传送给业务逻辑层，业务逻辑层完成相关业务规则和逻辑，并通过数据访问层访问数据库获得数据，然后按照相反的顺序依次返回将数据显示在表示层。有的三层结构还加了Factory、Model等其他层，实际都是在这三层基础上的一种扩展和应用.

一个简单的三层结构程序一般包括DAL BLL WEB Model几个项目，它们的相互引用关系如下  
1) WEB引用 BLL,Model  
2)BLL引用 DAL,Model  
3)DAL引用Model  
4)Model无引用

一提三层架构，大家都知道是表现层（UI），业务逻辑层（BLL）和数据访问层（DAL），而且每层如何细分也都有很多的方法。但具体代码怎么写，到底那些文件算在哪一层，却是模模糊糊的。下面用一个简单的例子来带领大家实战三层架构的项目，这个例子只有一个功能，就是用户的简单管理。

首先建立一个空白解决方案，添加如下项目及文件  
1、添加ASP.NET Web Application项目，命名为UI，新建Web Form类型文件User.aspx（含User.aspx.cs）  
2、添加ClassLibrary项目，命名为BLL，新建Class类型文件UserBLL.cs  
3、添加ClassLibrary项目，命名为DAL，新建Class类型文件UserDAL.cs。添加SQLHelper引用。（这个是微软的数据访问类，也可以不用，直接编写所有的数据访问代码。我一般用自己写的数据访问类DataAccessHelper ）。  
4、添加ClassLibrary项目，命名为Model，新建Class类型文件UserModel.cs  
5、添加ClassLibrary项目，命名为IDAL，新建Interface类型文件IUserDAL.cs  
6、添加ClassLibrary项目，命名为ClassFactory  
相信大家已经看出来了，这个和Petshop的示例没什么区别，而且更简单，因为在下也是通过Petshop学习三层架构的。但一些朋友对于这几个项目所处的层次，以及它们之间的关系，可能比较模糊，这里逐个说明一下：  
1、User.aspx和User.aspx.cs  
这两个文件（以及文件所属的项目，下面也是如此，不再重复强调了）都属于表现层部分。User.aspx比较好理解，因为它就是显示页面了。User.aspx.cs有些人觉得不应该算，而是要划到业务逻辑层中去。如果不做分层的话，那么让User.aspx.cs来处理业务逻辑，甚至操作数据库都没什么问题，但是做分层的话，这样就不应该了。在分层结构中，User.aspx.cs仅应该处理与显示有关的内容，其它部分都不应该涉及。  
举例：我们实现用列表方式显示用户的功能，那么提取信息的工作是由BLL来做的，UI（本例中是User.aspx.cs）调用BLL得到UserInfo后，通过代码绑定到User.aspx的数据控件上，就实现了列表的显示。在此过程中User.aspx.cs对UI没有起到什么作用，仅是用来传递数据，而且因为实际编码中大部分情况都是如此的实现，所以使有些人觉得User.aspx.cs不应该算UI，而应该并入BLL负责逻辑处理。继续往下看，这时提出了一个新需求，要求在每个用户的前面加一个图标，生动地表现出用户的性别，而且不满18岁的用儿童图标表示。这个需求的实现，就轮到User.aspx.cs来做了，这种情况下User.aspx.cs才算有了真正的用途。  
2、NewBLL.cs  
添加如下方法：  
public IList GetUsers()：返回所有的用户信息列表  
public UserInfo GetUser(int UserId)：返回指定用户的详细信息  
public bool AddUser(UserInfo User)：新增用户信息  
public bool ChangeUser(UserInfo User)：更新用户信息  
public void RemoveUser(int UserId)：移除用户信息  
此文件就属于业务逻辑层了，专门用来处理与业务逻辑有关的操作。可能有很多人觉得这一层唯一的用途，就是把表现层传过来的数据转发给数据层。这种情况确实很多，但这只能说明项目比较简单，或者项目本身与业务的关系结合的不紧密（比如当前比较流行的MIS），所以造成业务层无事可做，只起到了一个转发的作用。但这不代表业务层可有可无，随着项目的增大，或者业务关系比较多，业务层就会体现出它的作用来了。  
此处最可能造成错误的，就是把数据操作代码划在了业务逻辑层，而把数据库作为了数据访问层。  
举例：有些朋友感觉BLL层意义不大，只是将DAL的数据提上来就转发给了UI，而未作任何处理。看一下这个例子  
BLL层  
SelectUser（UserInfo userInfo）根据传入的username或email得到用户详细信息。  
IsExist（UserInfo userInfo）判断指定的username或email是否存在。  
然后DAL也相应提供方法共BLL调用  
SelectUser（UserInfo userInfo）  
IsExist（UserInfo userInfo）  
这样BLL确实只起到了一个传递的作用。  
但如果这样做：  
BLL.IsExist（Userinfo userinfo）  
\{  
UerInfo user = DAL.SelectUser（User）；  
return (userInfo.Id != null);  
\}  
那么DAL就无需实现IsExist()方法了，BLL中也就有了逻辑处理的代码。  
3、UserModel.cs  
实体类，这个东西，大家可能觉得不好分层。包括我以前在内，是这样理解的：UI?àModel?àBLL?àModel?àDAL，如此则认为Model在各层之间起到了一个数据传输的桥梁作用。不过在这里，我们不是把事情想简单，而是想复杂了。  
Model是什么？它什么也不是！它在三层架构中是可有可无的。它其实就是面向对象编程中最基本的东西：类。一个桌子是一个类，一条新闻也是一个类，int、string、doublie等也是类，它仅仅是一个类而已。  
这样，Model在三层架构中的位置，和int，string等变量的地位就一样了，没有其它的目的，仅用于数据的存储而已，只不过它存储的是复杂的数据。所以如果你的项目中对象都非常简单，那么不用Model而直接传递多个参数也能做成三层架构。  
那为什么还要有Model呢，它的好处是什么呢。下面是思考一个问题时想到的，插在这里：  
Model在各层参数传递时到底能起到做大的作用？  
在各层间传递参数时，可以这样：  
AddUser（userId，userName，userPassword，…，）  
也可以这样：  
AddUser（userInfo）  
这两种方法那个好呢。一目了然，肯定是第二种要好很多。  
什么时候用普通变量类型（int,string,guid,double）在各层之间传递参数，什么使用Model传递？下面几个方法：  
SelectUser（int UserId）  
SelectUserByName（string username）  
SelectUserByName（string username，string password）  
SelectUserByEmail（string email）  
SelectUserByEmail（string email，string password）  
可以概括为：  
SelectUser（userId）  
SelectUser（user）  
这里用user这个Model对象囊括了username，password，email这三个参数的四种组合模式。UserId其实也可以合并到user中，但项目中其它BLL都实现了带有id参数的接口，所以这里也保留这一项。  
传入了userInfo，那如何处理呢，这个就需要按照先后的顺序了，有具体代码决定。  
这里按这个顺序处理  
首先看是否同时具有username和password，然后看是否同时具有email和password，然后看是否有username，然后看是否有email。依次处理。  
这样，如果以后增加一个新内容，会员卡（number），则无需更改接口，只要在DAL的代码中增加对number的支持就行，然后前台增加会员卡一项内容的表现与处理即可。  
4、UserDAL.cs  
public IList SelectUsers()：返回所有的用户信息列表  
public UserInfo SelectUser(int UserId)：返回指定用户的相信信息  
public bool InsertUser(UserInfo User)：新增用户信息  
public bool UpdateUser(UserInfo User)：更新用户信息  
public void DeleteUser(int UserId)：移除用户信息  
很多人最闹不清的就是数据访问层，到底那部分才算数据访问层呢？有些认为数据库就是数据访问层，这是对定义没有搞清楚，DAL是数据访问层而不是数据存储层，因此数据库不可能是这一层的。也有的把SQLHelper（或其同类作用的组件）作为数据访问层，它又是一个可有可无的东西，SQLHelper的作用是减少重复性编码，提高编码效率，因此如果我习惯在乎效率或使用一个非数据库的数据源时，可以丢弃SQLHelper，一个可以随意弃置的部分，又怎么能成为三层架构中的一层呢。  
可以这样定义：与数据源操作有关的代码，就应该放在数据访问层中，属于数据访问层  
5、IUserDAL  
数据访问层接口，这又是一个可有可无的东西，因为Petshop中带了它和ClassFactory类工厂，所以有些项目不论需不需要支持多数据源，都把这两个东西做了进来，有的甚至不建ClassFactory而只建了IDAL，然后“IUserDAL iUserDal = new UserDAL();”，不知意义何在。这就完全是画虎不成反类犬了。  
许多人在这里有一个误解，那就是以为存在这样的关系：BLL?àIDAL?àDAL，认为IDAL起到了BLL和DAL之间的桥梁作用，BLL是通过IDAL来调用DAL的。但实际是即使你如此编码：“IUserDAL iUserDal = ClassFacotry.CreateUserDAL()；”，那么在执行“iUserDal.SelectUsers()”时，其实还是执行的UserDAL实例，而不是IUserDAL实例，所以IDAL在三层中的位置是与DAL平级的关系。  
通过上面的介绍，基本上将三层架构的层次结构说明了。其实，本人有一个判断三层架构是否标准的方法，那就是将三层中的任意一层完全替换，都不会对其它两层造成影响，这样的构造基本就符合三层标准了（虽然实现起来比较难^\_^）。例如如果将项目从B/S改为C/S（或相反），那么除了UI以外，BLL与DAL都不用改动；或者将SQLServer改为Oracle，只需替换SQLServerDAL到OracleDAL，无需其它操作等等。本来想在文中加入一些具体的代码的，但感觉不是很必要，如果大家觉得需要的话，我再补充吧。  
总结：不要因为某个层对你来说没用，或者实现起来特别简单，就认为它没有必要，或者摒弃它，或者挪作它用。只要进行了分层，不管是几层，每一层都要有明确的目的和功能实现，而不要被实际过程所左右，造成同一类文件位于不同层的情况发生。也不要出现同一层实现了不同的功能的情况发生。

[1355062119_9401.jpg]: https://img-my.csdn.net/uploads/201212/09/1355062119_9401.jpg