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

首先AppCode中，放的是通用类，如数据库通用类，实现数据库连接，主要的SqlCommand创建，自己定义CRUD的方法等，与三层架构毫无关系，就是经常使用的开发模式中存放类(Class)的目录。

其次，当使用三层架构时，一定是在大项目中，由于三层架构的目的是提高项目的松散性和减少项目的耦合度，使之更easy扩展或者维护。小项目使用了三层架构，由于过度的在意分层而导致了项目的复杂度添加。

创建三层架构的应用程序。我们必须对这三层分别创建不同的类库(ClassLibrary)，而不是普通的类(Class)。我们对于不论什么一个模块或者功能进行OOP，把它扩展为对象(面向对象的思想就是：将所操作的目标当成一个对象，对它进行的操作，将由对象自己的方法进行，而非外界传參。譬如注冊用户，用面向过程的方法事先，就是:public static bool Register(string userName, string userPwd)。若用OO的思想，我们不可将账号password作为參数传入，而是将用户作为一个对象，这个对象具有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层就是操作抽象出来的实体对象，它包括了各种属性。

一个三层架构的小样例：注冊新用户。

先写模块的实体类，是数据库中表的抽象，如果数据库中注冊信息仅仅有账号，password两个字段。那么抽象到实体类就是这样：

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 = http://www.mamicode.com/uInfo.UserName; //调用实体类的属性"@pwd", SqlDbType.NVarChar, 50).Value = http://www.mamicode.com/uInfo.UserPwd;"SELECT * FROM UserInfo WHERE Name=@name"; SqlCommand cmd=new SqlCommand(sqlStr); cmd.Parameters.Clear(); cmd.Parameters.Add("@name", SqlDbType.NVarChar, 50).Value = http://www.mamicode.com/name;"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层中先通过注冊名获得用户的详细信息，若能够获得则证明该username已被注冊，返回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层做了逻辑推断，假设username存在，则注冊失败。

三层架构的特点：

1.数据库訪问层(DAL)仅提供对数据库的CRUD操作，而无论操作后的结果，也无论逻辑过程(譬如同名用户，不合法username)。

2.业务逻辑层(BLL)不会直接与数据库交互，他与数据库的交互是通过DAL提供的方法。在调用这些方法前，要增加自己的逻辑推断或者业务处理。另外业务逻辑层(BLL)还有可能不会去调用DAL层的方法，而是进行其它业务处理。

3.用户界面层(UI)层是不会调用DAL层的，他仅仅调用BLL层提供的方法，再由BLL层自己决定是否继续调用DAL层。

这个样例能够看出三层架构的长处就是结构清晰，easy扩展与维护。缺点就是，复杂。只一个注冊用户，就这么麻烦，所以对于小项目来说，费这么大劲换取一个相对较清晰的分层结构是不划算的。

转载请注明出处：csdn-mark