请教一个简单三层架构中数据访问层的小问题。

Question

小弟想练习一下简单的ASP.NET三层架构，在网上查找了些资料，一般有UI BLL DAL Models这几个模块，其中Models是用来存放在各层之间传递的实体对象，现在我有个疑问。这个Models是按照网上说的，将数据库中的每个表写成一个类？还是就直接用DataSet 或者 DataTable 或者 DataRow？对于前一种方法，需要写大量的增删改SQL语句，而后一种办法可以直接和UI层的控件绑定，而且可以利用一部分.NET 自动生成的增删改语句。是不是后一种办法更好？或者还有别的区别什么的？欢迎大家讨论。

Answer 1

如果楼主是初学 就不要用生成的  models是实体类 以方便参数化的调用 

Answer 2

这里是界面层一般叫UI
protected void Button1_Click(object sender, EventArgs e)
{
 List<User> Users = BLL.GetUserInfo(txtUserName.Text,txtPassword.Text);
 
 if(Users.Length > 0)
 {
  Response.Write("登陆成功");
 }
 else
 {
  Response.Write("登陆失败");
 }
}以下是逻辑层代码,业务逻辑层一般叫BLL
public static List<User> GetUserInfo(string user,string password)
{
 string newPassword = GetMD5Hash(password); //这里对密码进行加密处理,数据库中存放的是经过MD5加密,业务逻辑层一般都是处理复杂的逻辑.例如加密逻辑
 List<User> Users = DAL.GetUserInfo(user,newPassword);
 
 return Users;
}以下是数据访问层代码,数据访问层一般叫DAL
public static List<User> GetUserInfo(string user,string password)
{
 List<User> Users = new List<User>();
 string sql = "select * from User where Password = '"+password+"' and User = '"+user+"'"; //写where子句的时候把Password放前面.因为Password经过加密,所以可以防止SQL注入攻击
 SqlDataAdapter da = new SqlDataAdapter(sql,"这里是数据库连接字符串");
 DataSet ds = new DataSet();
 da.Fill(ds);
 
 for(int i=0;i<ds.Tables[0].Rows.Count;i++)
 {
  User user = new User(ds.Tables[0].Rows[i]["ID"].ToString(),ds.Tables[0].Rows[i]["User"].ToString(),ds.Tables[0].Rows[i]["Password"].ToString());
  Users.Add(user);
 }
 
 return Users;
}还会有一个Model层.叫做模板层.是数据表结构的印射.Model层是共用层,其他三层都要用到.
比如数据库中有张表User,里面有3个字段ID,User,Password
那么在模板层中应该有一个类,数据库中User表的一行对应一个User对象,一张表对应User对象的集合.
public class User
{
 string ID;
 string User;
 string Password;
 
 //重载构造函数
 User(string id,string user,string password)
 {
  this.ID=id;
  this.User=user;
  this.Password=password;
 }
}随便去网上搜索一下一大堆。。三层自己写下就熟悉了。。

Answer 3

LZ的疑问应该是体现在model这个上面，三层架构，UI层，业务逻辑层BLL，数据访问层（DAL+Model），其实不管你的数据类型是什么，是采用实体结构的还是用强类型dataset、datatale都取决于项目中后期维护、其实在使用dataSet、datatable其实在数据访问层没什么大的问题，但是在BLL层和UI层去访问数据类型的时候，就会在使用数据时要指明字段名等等，所谓的硬编码，即在后期维护如果修改了某个字段名称、类型或者表名，那么受影响的UI层和BLL层都要修改，这样查找起来是非常费劲的，编译的时候根本不会出错，用实体类的话，字段名修改或其他属性修改，都能在编译的时候体现出来。在使用实体类结构做为数据类型使用的时候，多的一段代码其实体现在数据访问层（DAL），在取出数据的时候，要将从数据库读取的字段转换赋值到实体类上。
其实现在很多工具都能生成三层架构，例如codesmith，只要将一张表的增、删、查、改的基本4个方法分为BLL、DAL、model三层的写出来作为模板，然后将项目的表全部使用此模板生成出来，一个基本项目雏形就出现了，满足基本的增删查改，当然带有业务的业务逻辑得自己手写！估计半天都不需要。

Answer 4

如果你想学“三层”，就别动不动纠缠数据库SQL语句的。凡是知道将表现层的设计与数据库分离，并且付诸于行动的，就是三层。基于此，你再来看你的什么DataTable之类的，是站在表现层说事吧？那么纠结什么数据库SQL语句干什么？你所说的Model之类的，还有必要扯上SQL语句来作为设计元素么？重点应该是看前后台通讯，而不是什么数据库SQL语句操作！

Answer 5

当你设计Model的时候，如果基本概念具备，对于“网上说的，将数据库中的每个表写成一个类”这种话就有天然的免疫力，知道这很可能是出自什么人的思维定势。

Answer 6

datatable那东西太麻烦了，类型要转来转去的，还得自己去填字段名称。

Answer 7

让我们也能够轻量级基于ajax的web应用能够程序做个示例。当你规划一个迭代周期中30个页面，每一个页面都有一个初始数据内容（通过http get命令而获得），并且每一个页面都有几个对后台服务系统的通讯命令（主要是通过http post命令获得）并且由前端javascript程序更新页面，最后就形成了这30个页面。那么在设计这个web应用程序时，你无需去想当然地去假设服务器如何实现，你只需要定义get和post命令的接口就行了。这就是分层设计。

Answer 8

其实我也想问问，我之前说的难道没有用到分层架构的优点吗？是纯粹的为了分层而分层吗？只是形式主义吗？对于你的话，我有点想法，可能不对，请见谅：
三层架构是提供了可移植性、可维护性、可复用性、能够脱离UI层在interface层上调用等优点！
按照你所说的，如果不能脱离UI层调用，就算不上分层设计了么？ 其实大多数情况下不是开发，就一定按照项目的情况来决定的，不是说我们一定要用到分层架构的所有特性才能使用分层架构，而是根据自己项目的需要，来取舍的，我们要保持分层架构的优点，但是有的优点在项目中就用不上，难道我们要硬要加进去，来搪塞所谓什么是分层架构？ 
分层架构对开发人员来说提供的只是一个思路而已。只要满足项目的需要和将来的扩展，进行合理的设计，都可以叫做分层架构。项目是有生命长短的和局限性的，我们使用合理的架构只是延长一点项目的寿命，不过到了该重构的时候就得重构，架构的思路可以一直延续，不管语言怎么变化，环境怎么变化，我们都可以按照这样的思路做不同的项目。