浅谈C++三层架构

时间:2023-02-02 20:20:26

浅谈C++三层架构

三层架构并不是MVC,MVC是一个很早就有的经典的程序设计模式,M-V-C分为三层,M(Model)-V(View)-C(Control)。
web开发中的三层架构是指:数据访问层(DAL-DatabaseAccessLayer),业务逻辑层(BLL-BusinessLoginLayer),以及用户界面层(UI-UserInterface,实际就是网页后台的具体调用BLL层)。这个是基本概念。曾经我以为三层架构就是在AppCode中,分为三个大类与若干小类,各司其职。在经过一番洗礼后,才发觉多么的无知。

首先AppCode中,放的是通用类,如数据库通用类,实现数据库连接,基本的SqlCommand创建,自定义CRUD的方法等,与三层架构毫无关系,就是常用的开发模式中存放类(Class)的文件夹。

其次,当使用三层架构时,一定是在大项目中,因为三层架构的目的是提高项目的松散性和降低项目的耦合度,使之更容易扩展或者维护。小项目使用了三层架构,由于过度的在意分层而导致了项目的复杂度增加。

创建三层架构的应用程序。我们必须对这三层分别创建不同的类库(ClassLibrary),而不是普通的类(Class)。
我们对于任何一个模块或者功能进行OOP,把它扩展为对象(面向对象的思想就是:将所操作的目标当成一个对象,对它进行的操作,将由对象自己的方法进行,而非外界传参。譬如注册用户,用面向过程的方法事先,就是:public static bool Register(string userName, string userPwd)。
若用OO的思想,我们不可将账号密码作为参数传入,而是将用户作为一个对象,这个对象具有private _userName,和private _userPwd的属性。在注册时,用构造函数初始化一个新的对象,User one = new User(userName,userPwd),使之在初始化后具有这两个字段的值。然后调用User类中的public static bool Register()方法(注意这个方法是不进行传参的),而在这个Register方法中,使用对象的_userName和_userPwd属性进行注册。),那么,我们在这个对象中的任何操作都将以该对象的方法(函数)实现。

在进行三层分类时,这样新建类库。
1.文件->新建项目->其他项目类型->空白解决方案。
2.在右侧的“资源管理器”中,选中当前解决方案,右键添加->新建项目->类库(ClassLibrary),分别创建BLL,DAL,UL类库。(若添加后看不到解决方案则在菜单->工具->选项->项目和解决方案->总是显示解决方案)。
3.右键,向解决方案中添加一个网站(新网站或者现有网站)。
4.根据需求删除或者保留默认添加项(默认的class1.cs或Default.aspx文件)。

这样一个三层架构的网站雏形就搭建好了。因为UI层要被其他两层引用,DAL层要被BLL层引用。所以需要相互添加引用,方法是在类库上点击右键->添加引用->项目->选择其他类库。并且在具体类中引入命名空间(using namespace)。

ps:类库其实就是类的集合,三层架构的目的就是,将同一项目的不同模块都划分为各自的三层,各司其职,将具体实现方法用类写出,添加到该层的类库中,这样,一个网站下的类库就只有三层,每一层中都包含了各个模块相对应层的实现方法。在以后修改或扩展时,在对应层中进行操作就可以了。

一般的项目,涉及最多的就是对数据库的CRUD,DAL层只负责与数据库的交互,BLL层是最重要的一层,他负责将DAL层的的结果呈现给UI层,但是恰恰BLL层的存在似乎有点鸡肋,他起到的仅仅是转发DAL层数据的作用,而具体的逻辑操作是与数据库的交互,应该写在DAL层,这就好像BLL层是在重复DAL层的劳动一样,其实BLL层的作用在于除了调用DAL层访问数据库,还可以进行逻辑判断,当符合的时候,才进行允许进行DAL的操作,或者进行额外的操作(如加密,转换等)。而DAL层可不管这些,他只管进行CRUD的动作。UI层就是操作抽象出来的实体对象,它包含了各种属性。

一个三层架构的小例子:注册新用户。
先写模块的实体类,是数据库中表的抽象,假设数据库中注册信息只有账号,密码两个字段。那么抽象到实体类就是这样:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Entity
{
class UserInfo
{
public string UserName { get; set; } //C#3.0中属性构造器的新写法;
public string UserPwd { get; set; }
}
}

再写DAL层:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data;
using System.Data.SqlClient;
using Entity; //这里添加对Entity实体类的引用;
namespace DAL
{
public class UserDAL
{
//在该类中,为了方便,一般会构造一个DataBaseFactory,方便进行代码的操作。所以以下代码仅为逻辑实现,不代表代码正确。
public bool AddUser(UserInfo uInfo) //这里将实体类作为参数传入;
{
string sqlStr="INSERT INTO UserInfo(Name,Pwd) VALUES(@name,@pwd)";
SqlCommand cmd=new SqlCommand(sqlStr);
cmd.Parameters.Clear();
cmd.Parameters.Add("@name", SqlDbType.NVarChar, 50).Value = uInfo.UserName; //调用实体类的属性
cmd.Parameters.Add("@pwd", SqlDbType.NVarChar, 50).Value = uInfo.UserPwd;
return Convert.ToInt32(cmd.ExecuteNonQuery()) > 0 ? true : false;
}
public DataTable GetUserInfo(string name) //根据用户名获得用户的具体信息
{
string sqlStr="SELECT * FROM UserInfo WHERE Name=@name";
SqlCommand cmd=new SqlCommand(sqlStr);
cmd.Parameters.Clear();
cmd.Parameters.Add("@name", SqlDbType.NVarChar, 50).Value = name;
SqlDataAdapter sda = new SqlDataAdapter(cmd);
DataSet ds=new DataSet();
sda.Fill(ds,"UserInfo");
return ds.Tables["UserInfo"];
}
}
}

再写BLL层:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data;
using Entity; //添加对Entity类库的引用
using DAL; //添加对DAL类库的引用
namespace BLL
{
public class UserBLL
{
public static bool AddUser(UserInfo uInfo) //BLL层的方法多为静态方法,DAL层也可以为静态方法。
{
UserDAL uDal = new UserDAL();
DataTable dTable = uDal.GetUserInfo(uInfo.UserName);
if (dTable.Rows.Count > 0) //这里对注册用户有一个判断,从DAL层中先通过注册名获得用户的具体信息,若可以获得则证明该用户名已被注册,返回false;
return false;
else
return uDal.AddUser(uInfo);
}
}
}

最后构建UI层代码,即我们的aspx.cs页面代码,该层应该直接调用BLL层的方法。该页面引用BLL和Entity的命名空间,并向Button控件注册事件:
protected void btnRegister_OnClick(object sender, EventArgs e)
{
UserInfo uInfo = new UserInfo(textUserName.text, textUserPwd.text);
if (UserBLL.AddUser(uInfo))
Response.Write("注册成功!");
else
Response.Write("注册失败!");
}

这样一个小的三层架构程序就出来了。
这个程序中,操作的实体为UserInfo表的抽象。在DAL层进行了AddUser()的方法,在BLL层也进行了AddUser()的方法,唯一的区别是BLL层做了逻辑判断,如果用户名存在,则注册失败。

三层架构的特点:
1.数据库访问层(DAL)仅提供对数据库的CRUD操作,而不管操作后的结果,也不管逻辑过程(譬如同名用户,不合法用户名)。
2.业务逻辑层(BLL)不会直接与数据库交互,他与数据库的交互是通过DAL提供的方法。在调用这些方法前,要加入自己的逻辑判断或者业务处理。另外业务逻辑层(BLL)还有可能不会去调用DAL层的方法,而是进行其他业务处理。
3.用户界面层(UI)层是不会调用DAL层的,他只调用BLL层提供的方法,再由BLL层自己决定是否继续调用DAL层。

这个例子可以看出三层架构的优点就是结构清晰,容易扩展与维护。缺点就是,复杂。仅仅一个注册用户,就这么麻烦,所以对于小项目来说,费这么大劲换取一个相对较清晰的分层结构是不划算的。

软件的三层架构

(一)概述
在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。微软推荐的分层式结构一般分为三层,从下至上分别为:数据访问层、业务逻辑层(又或称为领域层)、表示层。
1、表示层(UI):通俗讲就是展现给用户的界面,即用户在使用一个系统的时候他的所见所得。
2、业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。
3、数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、查找等。

(二)三层结构原理:
3个层次中,系统主要功能和业务逻辑都在业务逻辑层进行处理。
所谓三层体系结构,是在客户端与数据库之间加入了一个“中间层”,也叫组件层。这里所说的三层体系,不是指物理上的三层,不是简单地放置三台机器就是三层体系结构,也不仅仅有B/S应用才是三层体系结构,三层是指逻辑上的三层,即使这三个层放置到一台机器上。三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下,客户端不直接与数据库进行交互,而是通过COM/DCOM通讯与中间层建立连接,再经由中间层与数据库进行交互。

(三)各层的作用
数据访问层:
有时候也称为是持久层,其功能主要是负责数据库的访问,可以访问数据库系统、二进制文件、文本文档或是XML文档。简单的说法就是实现对数据表的Select,Insert,Update,Delete的操作。如果要加入ORM的元素,那么就会包括对象和数据表之间的mapping,以及对象实体的持久化。主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层,而不是指原始数据,也就是说,是对数据的操作,而不是数据库,具体为业务逻辑层或表示层提供数据服务。

业务逻辑层:
主要是针对具体的问题的操作,也可以理解成对数据层的操作,对数据业务逻辑处理,如果说数据层是积木,那逻辑层就是对这些积木的搭建。业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计,也即是说它是与系统所应对的领域(Domain)逻辑有关,很多时候,也将业务逻辑层称为领域层。
例如Martin Fowler在《Patternsof Enterprise Application Architecture》一书中,将整个架构分为三个主要的层:表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans,对业务逻辑层作了更细致地划分,细分为应用层与领域层,通过分层进一步将领域逻辑与领域逻辑的解决方案分离。
业务逻辑层在体系架构中的位置很关键,它处于数据访问层与表示层中间,起到了数据交换中承上启下的作用。由于层是一种弱耦合结构,层与层之间的依赖是向下的,底层对于上层而言是“无知”的,改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时,遵循了面向接口设计的思想,那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下,理想的分层式架构,应该是一个支持可抽取、可替换的“抽屉”式架构。
正因为如此,业务逻辑层的设计对于一个支持可扩展的架构尤为关键,因为它扮演了两个不同的角色。对于数据访问层而言,它是调用者;对于表示层而言,它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上,如何实现依赖关系的解耦,则是除了实现业务逻辑之外留给设计师的任务。

表示层:
位于最外层(最上层),离用户最近。用于显示数据和接收用户输入的数据,为用户提供一种交互式操作的界面。主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成:aspx, 如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务。

(四)具体调用
微软的DNA架构定义了三个层:表示层(presentation),业务逻辑层(business),和数据访问层(data access)。具体又分为:界面外观层、界面规则层、业务接口层、业务逻辑层、实体层、数据访问层、数据存储层共七层,其具体的调用如图1所示:

(五)规则
1.系统各层次及层内部子层次之间都不得跨层调用。
2.Entityobject 在各个层之间传递数据。
3.需要在UI层绑定到列表的数据采用基于关系的DataSet传递,除此之外,应该使用Entityobject传递数据。
4.对于每一个数据库表(Table)都有一个DB Entity class与之对应,针对每一个Entityclass都会有一个BEM Class与之对应。
5.有些跨数据库或跨表的操作(如复杂的联合查询)也需要由相应的BEM Class来提供支持。
6.对于相对简单的系统,可以考虑将Business Function子层和Business Flow 子层合并为一个。
7.UI层和BL层禁止出现任何SQL语句。

为什么要使用三层架构

对于一个简单的应用程序来说,代码量不是很多的情况下,一层结构或二层结构开发完全够用,没有必要将其复杂化,如果对一个复杂的大型系统,设计为一层结构或二层结构开发,那么这样的设计存在很严重缺陷。下面会具体介绍,分层开发其实是为大型系统服务的。在开发过程中,初级程序人员出现相似的功能经常复制代码,那么同样的代码写那么多次,不但使程序变得冗长,更不利于维护,一个小小的修改或许会涉及很多页面,经常导致异常的产生使程序不能正常运行。
最主要的面向对象的思想没有得到丝毫的体现,打着面向对象的幌子却依然走着面向过程的道路。意识到这样的问题,初级程序人员开始将程序中一些公用的处理程序写成公共方法,封装在类中,供其它程序调用。例如写一个数据操作类,对数据操作进行合理封装,在数据库操作过程中,只要类中的相应方法(数据添加、修改、查询等)可以完成特定的数据操作,这就是数据访问层,不用每次操作数据库时都写那些重复性 的数据库操作代码。在新的应用开发中,数据访问层可以直接拿来用。面向对象的三大特性之一的封装性在这里得到了很好的体现。现在找到了面向对象的感觉,代码量较以前有了很大的减少,而且修改的时候也比较方便,也实现了代码的重用性。

与MVC的区别
MVC是三个单词的缩写,分别为:模型(Model),视图(View)和控制Controller)。 MVC模式的目的就是实现Web系统的职能分工。 Model层实现系统中的业务逻辑,通常可以用JavaBean或EJB来实现。 View层用于与用户的交互,通常用JSP来实现。 Controller层是Model与View之间沟通的桥梁,它可以分派用户的请求并选择恰当的视图以用于显示,同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。
同样是架构级别的,相同的地方在于他们都有一个表现层,但是他们不同的地方在于其他的两个层。

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