三层开发中容易犯的错误 今天看了这边文章 感触很深 回头看看自己生成的三层架构代码 发现自己犯了架构性的大错
误,我当时考虑三层架构也明白每层所需的工作 但是在用生成器生成三层后 发现如果以后要扩展方法 需要在业务逻
辑层(下文简称BLL) 和数据访问层(下文简称DAL)层中都需要修改。。这样大大的加大了工作量
比如我要扩展个验证用户名密码的方法,我当时考虑是把这个方法放在DAL 还是BLL里。。
如果放在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编程上有所帮助。
误,我当时考虑三层架构也明白每层所需的工作 但是在用生成器生成三层后 发现如果以后要扩展方法 需要在业务逻
辑层(下文简称BLL) 和数据访问层(下文简称DAL)层中都需要修改。。这样大大的加大了工作量
比如我要扩展个验证用户名密码的方法,我当时考虑是把这个方法放在DAL 还是BLL里。。
1
public 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![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
2
![](https://www.cnblogs.com/Images/OutliningIndicators/ExpandedBlockStart.gif)
3
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
4
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
5
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
6
![](https://www.cnblogs.com/Images/OutliningIndicators/ExpandedSubBlockStart.gif)
7
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
8
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
9
![](https://www.cnblogs.com/Images/OutliningIndicators/ExpandedSubBlockEnd.gif)
10
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
11
![](https://www.cnblogs.com/Images/OutliningIndicators/ExpandedSubBlockStart.gif)
12
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
13
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
14
![](https://www.cnblogs.com/Images/OutliningIndicators/ExpandedSubBlockEnd.gif)
15
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
16
![](https://www.cnblogs.com/Images/OutliningIndicators/ExpandedSubBlockStart.gif)
17
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
18
![](https://www.cnblogs.com/Images/OutliningIndicators/ExpandedSubBlockEnd.gif)
19
![](https://www.cnblogs.com/Images/OutliningIndicators/InBlock.gif)
20
![](https://www.cnblogs.com/Images/OutliningIndicators/ExpandedBlockEnd.gif)
21
![](https://www.cnblogs.com/Images/OutliningIndicators/None.gif)
如果放在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编程上有所帮助。