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

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

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

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

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

1public bool ValidateAdmin(string Ad_Accounts, string Ad_Password)

2

如果放在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编程上有所帮助。