三层学习完了，第一次验收的时候，自己理解的也不是非常到位，后来又又一次敲了一遍登陆样例，查阅了一些资料
进行第二次验收才感觉清晰了很多。之前画时序图时我就想过时序图基本上也是非常好的体现了三层，当时也和别人讨
论过这个问题。
直到学完三层后，更加证明了这一点。
以下我将从理论和实践两个角度总结一下三层。
理论篇
为什么使用三层架构？
说白了，分层的目的是想将复杂问题简单化，也就是面向对象技术所崇尚的“高内聚，低耦合”。当业务复杂到
一定程度。数据存储在独立的存储介质时适合用三层架构。
什么是三层架构？
通常意义上的三层架构(3-tier architecture)就是将整个业务应用划分为：表现层（UI）、业务逻辑层
（BLL）、数据訪问层（DAL）。
图解
表现层（UI）：主要是指人机交互界面。用于接收用户输入的数据和显示处理后用户须要的数据。
业务逻辑层（BLL）：连接UI和DAL的桥梁。
数据訪问层（DAL）：实现数据库的增、删、改、查。
实体类（Model）：不属于三层的范畴，个人理解的建立实体类的目的是将加载的数据库中的数据放入当中，
UI、BLL、DAL。哪个须要就从实体类中获取。封装数据，避免了传參数造成的复杂，从而避免了各个层与数据库的直
接接触，造成数据交叉。各个层仅仅须要和实体层Model打交道就可以。
点睛
各个层各司其职，仅仅负责自己专属的功能。提高了内聚性，降低了彼此之间的耦合。Model是数据传输的业务数
据模型，不是数据库中的数据。Model是避免出现数据交而建立的。
怎样搭建？
优缺点？
长处
1、开发者能够仅仅关注整个结构中的当中某一层。
2、能够减少层与层之间的依赖；
3、有利于标准化，能够非常easy的用新的实现来替换原有层次的实现。
4、在后期维护的时候，极大地减少了维护成本和维护时间
缺点
1、减少了系统的性能。这是不言而喻的。假设不採用分层式结构。非常多业务能够直接造訪数据库，以此获
取对应的数据。现在却必须通过中间层来完毕。
2、有时会导致级联的改动。这样的改动尤其体如今自上而下的方向。
假设在表示层中须要添加一个功能。为
保证其设计符合分层式结构，可能须要在对应的业务逻辑层和数据訪问层中都添加对应的代码。
3、添加了开发成本。
实战篇
以下是一个登录窗口的DEMO
UI层的代码
<span style="font-family:KaiTi_GB2312;font-size:18px;">namespace LoginUI
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void btnLogin_Click(object sender, EventArgs e)
{
string userName = txtUserName.Text.Trim();
string password = txtPassword.Text;
Login.BLL.LoginManager mgr = new Login.BLL.LoginManager(); //重载BLL层
Login.Model.UserInfo user = mgr.UserLogin(userName, password);
MessageBox.Show("登录用户：" + user.UserName);
}
}
}
</span>UI层，人机交互。须要引用BLL和Model层，从代码中能够看出UI层不包括不论什么逻辑推断的代码和跟数据库有关的
代码。
BLL层的代码
<span style="font-family:KaiTi_GB2312;font-size:18px;">namespace Login.BLL
{
public class LoginManager
{
public Login.Model.UserInfo UserLogin(string userName, string password) //获得Model中封装的数据库中的数据（UI层中的）
{
Login.DAL.UserDAO uDao = new Login.DAL.UserDAO(); //实例化UserDAO类
Login.Model.UserInfo user = uDao.SelectUser(userName, password);
if (user != null) // 加载成功
{
Login.DAL.ScoreDAO sDao = new Login.DAL.ScoreDAO(); //知道数据库连接成操作命令
sDao.UpdateScore(userName, 10);
return user;
}
else
{
throw new Exception("登录失败。");
}
</span>从代码中能够看出BLL层也不和数据库打交道，没有SQL语句。
须要引用DAL和Model层。
DAL层代码
<span style="font-family:KaiTi_GB231<span style="font-family: Arial, Helvetica, sans-serif;">2;font-size:18px;">namespace Login.DAL</span>
{
public class UserDAO
{
public Login.Model.UserInfo SelectUser(string userName, string password) //获取Model中的表中的数据，返回的是数据模型
{
using (SqlConnection conn = new SqlConnection(DbUtil.ConnString)) //建立数据库连接
{
SqlCommand cmd = conn.CreateCommand(); //表示要对 SQL Server 数据库运行的一个 Transact-SQL 语句或存储过程。 实例化一个接口,用以运行SQL指令
cmd.CommandText = @"SELECT ID, UserName, Password,Email
FROM USERS WHERE UserName=@UserName AND Password=@Password";
cmd.CommandType = CommandType.Text;
cmd.Parameters.Add(new SqlParameter("@UserName",userName)); //添加上面数据库连接中设的两个參数
cmd.Parameters.Add(new SqlParameter("@Password",password));
conn.Open(); //打开数据库
SqlDataReader reader = cmd.ExecuteReader();
Login.Model.UserInfo user = null; //默认值是Null
while (reader.Read()) //读取数据库中的数据
{
if (user == null)
{
user = new Login.Model.UserInfo(); //当Model是Null的话才载入数据
}
user.ID = reader.GetInt32(0);
user.UserName = reader.GetString(1);
user.Password = reader.GetString(2);
if (!reader.IsDBNull(3)) //假设Email不是Null的话，才干读取
{
user.Email = reader.GetString(3);
}
}
return user;
}
}
}
}
</span>
从代码中能够看出是直接和数据库打交道的，没有跟窗口控件有关的内容。须要引入Model层。
个人小结
分层的目标是为了“高内聚。低耦合”。分层可将复杂的简单化。当需求须要改变时，你仅仅须要该对应部分而不
用大范围的改动。分层还提高了可维护性和可扩展性，但并非全部的都要分层，业务逻辑简单，没有真正的数据存
储层这时就不须要分层，假设分层反而会添加复杂度。所以我们寻常在使用时要注意灵活应用。