三层架构开发中容易犯的错误

三层开发中容易犯的错误 今天看了这边文章 感触很深  回头看看自己生成的三层架构代码  发现自己犯了架构性的大错

误，我当时考虑三层架构也明白每层所需的工作  但是在用生成器生成三层后 发现如果以后要扩展方法 需要在业务逻

辑层（下文简称BLL） 和数据访问层（下文简称DAL）层中都需要修改。。这样大大的加大了工作量

比如我要扩展个验证用户名密码的方法，我当时考虑是把这个方法放在DAL 还是BLL里。。
       

 1public bool ValidateAdmin(string Ad_Accounts, string Ad_Password)
 2        {            bool ReturnValue = false;
 3            SqlDataReader dr = null;
 4            QueryParam qp = new QueryParam("tb_Admin", "*", string.Format(" Ad_Accounts='{0}' and  Ad_PassWord='{1}'", Ad_Accounts, Ad_PassWord), "Admin_Id ASC");
 5            try
 6            {
 7                dr = dal.GetList(qp);
 8                ReturnValue = dr.HasRows;
 9            }
10            catch (Exception ex)
11            {
12                string str = ex.Message;
13                return false;
14            }
15            finally
16            {
17                dr.Close();
18            }
19            return ReturnValue;
20}
21

如果放在DAL里  还需要在BLL设置个相同的方法来调用DAL中的ValidateAdmin方法  这样的话不是加大工作量吗？

在说我并不是在BLL拼接SQL语句  而是设置类的参数而已  所以我就把类似这些方法全部建在BLL层中。。

直到今天----------------------------------------------------------------

我看了文章后  虽然我不是他文章里写的那些错误  但是我还是仔细考虑了我的代码  虽然我是可以很方便的扩展方法了

但是越做到后面 BLL代码越多 DAL层中的代码几乎不用改变。。那么DAL就失去了他的意义了。。如果这样我还不如

直接调用DbHelperSQL.cs类中的方法直接访问数据库  还要数据访问层干什么用

每层都做自己的工作，各做各的 互相依赖。。

1。UI层页面显示层（一般是用来显示页面的控件，页面的CS类是用来获取用户输入控件的值从而传入BLL层）
2。BLL层业务逻辑层（一般是用来组织或验证页面传过来的参数，从而分别调用DAL层中的操作数据的方法）
3。DAL层数据访问层（一般是用来接收BLL层传过来的参数，组织成SQL语句也好，组织成存储过程参数也好，最后调用DBUtility层中访问数据库的静态方法）

大家可以发现一环扣一环的  1访问2访问3    然后返回3返回2返回1    这种循环操作  不可跳级访问 1不能直接跳到3访问  那么2就没意义了


希望看了这篇文章的人  马上查看你们的三层架构  是不是和我同样或者类似的问题，最后就是不要嫌多写几个方法麻烦 会影响性能之类的。。三层架构就是三层

必须每层都有自己的意义。。

自己都不知道写了这么多了，也不知道我现在的理解是不是正确，希望你们看完的高手可以给我点意见，刚接触这个三层架构的朋友希望对你们在.NET编程上有所帮助。