三层架构设计

大多情况下，实体类和数据库中的表是对应的，实体类的属性和表的字段对应，但这并不是一个限制，有可以出现一个实体类对应多个表，或者交叉对应的情况。
虽然现在分层的设计开发中，一般都是用实体类对应数据库的表。但是有些专家意见是慎用，因为如果把数据展示在页面上的话，从数据库中读出的DataSet本身就是XML形式，数据展示也用XML，如果用了实体类就多了一次转化。
}
}
public int DeleteByUserId(int UserId)
{
string sqltext=string.Format("DeleteFROM ShopUser WHERE UserId={0}", UserId);
using (SqlCommand comm = new SqlCommand(sqltext, conn))
第八章三层架构设计
在软件体系架构设计中，分层式结构是最常见，也是重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层、表示层。
8.1三层架构概述
与网络协议是分层一样，软件设计也要进行分层，分层的目的是为了实现“高内聚、低耦合”，采用“分而治之”的思想，把任务划分成子任务，逐个解决，易于控制，易于延展，易于多个进行项目合作。
3、数据访问层（DAL）：顾名思义，就是用于专门跟后台数据库进行交互，直接操纵数据库，实现数据库记录的增加、删除、修改、查询等。与具体数据库系统相关的对象只在这一层被引用，如System.Data。System.Data.SqlClient等命名空间的对象，数据访问层之外的地方都不应该出现对这些对象的引用。三层架构的框架模型如图8-1所示。
图7.2显示了实体对象在三层架构中传递数据的过程。
图8-2实体类在三层架构中的数据传递
分层的思想讲完了，在多人合作开发系统的过程中，就可以按层来划分任务，只要设计的时候把接口定义好，开发人员就可以同时开发，而且不会发生冲突，做前台的人不需要关心怎么实现到数据库中去查询、更新、删除和增加数据，他们只需要去调用相应的类就可以了。做数据访问层的人也不需要知道前台的事，定义好与其它层交互的接口，规定好参数就行，各个层都一样，做好自己的工作就可以了。这样的系统，清晰性、可维护性和可扩展性都非常强大，测试和修改也比较方便。
试问一下，我们用Access做后台开发的未分层程序，如果有一天因为数据量的增加，安全的需要等，数据库有Access变成了SQL Server，怎么办？网页代码文件中的所有程序都要重新修改，整个系统需要重新来做，这都是设计不合理惹的祸。
多层开发架构的出现很有效的解决了这样的问题。
三层架构中，各个层之间的分工是很明确的。面向对象嘛，就像一个公司中的部门一样，每个部门的分工是不一样的，是哪个部门的任务就有哪个部门完成，对应的，各个部门的维护工作也是各自完成且不会影响其它的部门，至少影响不是很大，否则就只能说明分工还不合理。采用三层架构设计系统，各层高内聚、低耦合，通过有效的协作来完成系统的高效运行，三层架构中出现上面说的问题，由于其将数据访问操作完全限定在数据访问层内，数据库发生了改变，我们只需要修改数据访问层，其它的地方不用修改。
using (SqlDataAdapter sda = new SqlDataAdapter())
{
sda.SelectCommand = comm;
DataSet ds = new DataSet();
sda.Fill(ds, "ShopUser");
return ds.Tables["ShopUser"].DefaultView;
using (SqlCommand comm = new SqlCommand(sqltext, conn))
set { _UserName = value; }
}
……
}
8.2.2数据访问层设计
数据访问层是专门跟后台数据库进行交互，直接操纵数据库，实现数据库记录的增加、删除、修改、查询等。
首先在解决方案中添加名为“BookShopDALLayer”的数据访问层项目，操作方法仍是右击解决方案名，依次单击“添加”|“新建项目”，弹出“添加新项目”对话框，选中“Visual C#”右边的“类库”，输入项目名并确定。
{
conn.Open();
int result = comm.ExecuteNonQuery();
conn.Close();
return result;
}
}
public int UpdatePartInfoByUserId(ShopUserModel objUser)
{
string sqltext = string.Format("UPDATE ShopUser SET XinMin='{1}',Sex='{2}',Birthday='{3}',Email='{4}' WHERE UserId = {0}", erId, objUser.XinMin, objUser.Sex, objUser.Birthday, objUser.Email);
SqlConnection conn;
public ShopUserDAL()
{
conn = new SqlConnection(strconn);
}
/// <summary>
///获取顾客信息数据表视图
/// </summary>
/// <returns></returns>
public DataView GetDataView()
接下来在这个实体类项目中逐个添加实体。右击项目名“BookShopModel”，选“添加”|“类”，输入类名“ShopUserModel”，它同时也做文件名，这个实体类文件就建好了，在其中输入类的私有成员变量，并依据这些成员变量构建相应的属性。大家应该清楚私有成员变量和相应属性的关系吧，属性实质是访问器，有读写特性及判断处理功能，它本身不保存数据，真正的数据是保存在它所读写的私有成员变量中，属性提高了私有成员变量的安全性。
{
SqlCommand comm= new SqlCommand("SELECT UserId,UserName,Passwords,Email,XinMin,Sex,Birthday,Address,Tel,Photo,Nation,Hobby,PersonURL FROM ShopUser", conn);
所谓的三层架构就是将整个业务应用划分为表示层、业务逻辑层和数据访问层，由数据访问层去访问数据库，十分有利于系统的开发、维护、部署和扩展。
那么我们为什么要使用分层开发呢，它有什么独特的优势呢？
对于简单的应用来说，没有必要搞得那么复杂，可以不进行分层，但是对一个大型系统来说这样的设计的缺陷就很严重了。面向对象的程序设计模式追求的是代码的通用性，可植性，可维护性、功能扩展，分层开发这种设计模式体现了面向对象的思想，而在页面的后台代码中直接访问数据库，实际上是打着面向对象的幌子却依然走着面向过程的老路。
下面结合具体的实例，来学习三层架构的应用。仍以“BookShopOnNet”数据库中顾客表“ShopUser”为例，用三层架构的方式实现对它的显示，以及增、删、改、查等操作。
顾客表的结构为：ShopUser(UserId int IDENTITY(1,1) NOT NULL,UserName varchar(30)NOT NULL,Passwords varchar(20) NOT NULL,Email varchar(30),XinMin nvarchar(5), Sex bit,Birthday datetime,Address nvarchar(50),Tel varchar(12),Photo varchar(50),Nation nvarchar(15),Hobby varchar(50),PersonURL varchar(50)。详细说明请见第五章。
{
private int _UserId;
private string _UserName;
……
public int UserId
{
get { return _UserId; }
set { _UserId = value; }
}
public string UserName
{
get { return _UserName; }
using BookShopModel;
用“using BookShopModel;”导入这个命名空间，是因为前面创建实体类时，用的是默认的命名空间，默认命名空间就是项目名。
这样构建出来的顾客表所对就的数据访问类ShopUserDAL的内容如下：
public class ShopUserDAL
{
static string strconn = ConfigurationManager.ConnectionStrings["connStr"].ConnectionString;
此项目产生后，由于其中的类要用到前面刚创建的项目名为“BookShopModel”的实体类，所以需要添加对它的引用，否则其中的实体类是不能被这个项目中的类所访问的。添加引用的方法是：右击此项目中的“引用”，选“添加引用”，弹出如图8-3所示的对话框，选择“项目”选择卡，其中列出了解决方案中的所有项目，选中实体类项目后确定即可。
图8-3添加引用对话框
然后用在此项目中添加“类”的方式，添加“ShopUserDAL”数据访问类，此类中要进行数据库的访问操作，所以在类的开头要导入下面的几个命名空间，以便使用其中的类。
using System.Configuration;
using System.Data;