//业务逻辑层的登录方法 public int Login(string userName, string password) {     return DataAccess.UserAccount.Login(userName, password); }

下面是数据层的登录方法：

//数据访问层的登录方法 public int Login(string userName, string password) {     SqlParameter[] parameters = new SqlParameter[]{         //     };     return SqlHelper.ExecuteProcedure("Login",parameters); }

下面是登录的存储过程：

CREATE PROC Login   @userName varchar(20),   @password varchar(20) AS   IF NOT EXISTS(SELECT * FROM UserAccount WHERE UserName = @userName)       RETURN -1   IF NOT EXISTS(SELECT * FROM UserAccount WHERE UserName = @userName AND password = @password)       RETURN 1   UPDATE UserAccount   SET LoginTimes = LoginTimes + 1   WHERE UserName = @userName   RETURN 0

分析：从上面三段代码中我们可以很显然得看到登录的业务逻辑已经全部被后移到了数据库的存储过程中。这样使用的三层结构就失去了意义，逻辑层名存实亡了；而数据库的压力会越来越大；我们修改业务逻辑的时候不是到逻辑层修改，而是要到数据库中去修改了。

3．将界面层上的数据组件（如SqlDataSource）作为参数传递到业务逻辑层去赋值

这样做的坏处很明显，本来是界面层依赖于业务逻辑层的，现在业务逻辑层反过来去依赖界面层的类，需要逻辑层引用System.Web命名空间，显然是错误的。

4．为了省事儿，不是直接将参数传递到业务逻辑层，而是通过HttpContext直接获得界面层应该传递的参数

例子：在系统设计的初期没有记录用户登录的IP地址，而到了后期发现了这个问题，要求纪录用户IP了，为了不修改业务逻辑层方法的定义，也不用修改界面层的调用方法，于是便写出了下面的代码：

public int Login(string userName, string password) {   string userIP = System.Web.HttpContext.Current.Request.UserHostAddress;   //follow is login steps }

这一点犯的错误和3中的错误相同，导致层之间形成了依赖环。

5．将事务处理放在数据访问层来做

事务处理应该放在业务逻辑层处理，原因是

1）事务的划分是根据业务逻辑来定义的，通常一个事务就代表完成了一个完整的逻辑操作；

2）一个业务逻辑可能有几个数据操作，修改几个表中的数据，而通常数据层的类的划分是根据数据库表来划分的，如果把事务处理放在数据访问层，那么业务层的方法需要调用两个以上的数据层方法时，就会出现执行两个事务的情况，显然这是不合理的。

总结：

1．在三层结构的划分中我们应该使三层各负其责，谁也不能越权，谁也不能懒惰，通常情况下，逻辑层应该在满足各负其责的条件下，尽可能的厚。

2．三层结构中的依赖关系很明确，界面层依赖于逻辑层，逻辑层依赖于数据访问层，不能互相依赖，而形成依赖环。

欢迎访问最专业的网吧论坛,无盘论坛,网吧经营,网咖管理,网吧专业论坛 https://bbs.txwb.com 关注天下网吧微信/下载天下网吧APP/天下网吧小程序，一起来超精彩