浅谈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里，则是由业务逻辑与访问数据组成的。