对三层构架的再理解

三层结构中是不是不应该在UI 和BLL中出现 sql 语句?1.如果在UI中有条件查询,怎么避免在BLL中出现拼sql语句的情况?2.如果要使用事务操作多个dal方法,怎么避免对dal修改?

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

绝对不应该在BLL UI 中出现sql所以你第一个问题是不存在的,BLL只负责定义条件查询的函数.而且是静态的.BLL 调用DAL 的函数. 之后拼sql是DAL的事.第二个问题其实不管DAL 的事,是数据库处于并发数据的问题.
这样的话如果业务有修改那么dal层不是改动很频繁吗?而且根据我的实际使用来说, 一改就是 UI,BLL,DAL一起改,增加了开发出错的几率
你要明白的是原则，而不是方法。如果不明白原则，就会出问题。比如做早点的，为什么不能往食物中添点地沟油？反正吃早点的也吃不出来，我还能省钱。如果没有原则，光讲方法，那么世界就乱套了。你为什么用三层？你用三层解决什么问题。如果你挠着头皮说我也不知道，反正领导让我做三层我就做三层。如果这样的话，你往BLL甚至PL（你说的UI）中添加点SQL又有什么不可以。因为你用三层不是为了解决问题而是作茧自缚，那么你自然想到的就是怎么容易怎么来。
理论上说，访问数据库部分只该在 DAL 中，BLL 把条件传送过去，由 DAL 依据条件拼接，如果是想事务操作多个 DAL ，那 DAL 方法必须能返回执行结果，或返回值或异常， BLL 根据返回结果选择回滚或执行下一步，但是这样很麻烦，也不安全，如果全是数据库操作，最好是将所有步骤封装在存储过程里，或是单个 DAL 方法启动数据库事务来处理。
恩我明白分层是为了减少数据和业务耦合我之所以这么问是因为我接手的很多项目中, UI层,和BLL层大量出现 sql语句我试着把拼凑sql语句的步骤放到DAL中,但是找不到好方法能"通用"的把UI层的条件传递给DAl另外在我的项目中BLL几乎变成了一个传声筒 ,BLL 到底要做些什么事呢?
你明白的不全面。为什么要区分bll和dal，因为有可能（注意是有可能，不是一定）你有动机需要在程序中使用多种数据库或者持久化方案。典型地，你编写了一个网站，你的客户中一些买了MS SQL Server，另一些买了Oracle。你希望他们都能使用你的系统，而不必再次投资数据库。当然一种做法是为他们各自开发一套软件，但是使用分层，你就可以只开发同一套软件，并且用不同的dal搭配给不同的用户。表面上看，bll像一个传声筒，然而它传递相同的声音，却可以控制不同的数据库。此时，那些和具体数据库相关的东西（比如某个函数在Oracle支持，MSSQL不支持，或者某个功能在MSSQL使用存储过程，而Oracle则使用了视图），都应该摆在dal中，而和具体数据库无关的事情，则可以摆在BLL中。除了不断更换数据库以外，如果软件可能使用多种数据库访问技术，比如有需求将软件由直接对ADO.NET平滑迁移到使用一种ORM框架上来，那么同样地，增加dal可以减少对现有代码的修改。然而，如果你并不需要多种数据库实现，或者多种数据库访问的实现，你非要分出一个bll或者dal自然没有意义，做没有意义的事情自然想破头皮也想不通为什么，只是看着人家这么做，自己也这么做而已。
如果你的项目中BLL几乎都成了一个传声筒,那说明你根本没有分开这几层的必要.因为在简单的增删编的纯纯数据库应用中,没有很复杂的业务逻辑,那BLL就没有存在的必要.
在.net中  aspx 页面的 cs 文件和 BLL 的功能应该怎么划分呢?
那么BLL除了上面那么事情外,还有些什么任务?
你的说法不够全面.并不是说单单为了适应不同的数据库,我们就需要三层架构.而是说三层架构对于业务逻辑稍微复杂一点的项目来说是个自然而然的结果.原因是稍微复杂一点的业务逻辑要求我们面对的必须是对象,而不是数据库,或者XML,又或者DataTable 等等.所以必须有一个从数据文件转换到对象的过程.这就是DAL真正的功能.而适应不同的数据源只是它其中的一项功能. 而不是说如果我们不用三层架构,就无法适应不同的数据源.
你的说法不够全面.并不是说单单为了适应不同的数据库,我们就需要三层架构.而是说三层架构对于业务逻辑稍微复杂一点的项目来说是个自然而然的结果.原因是稍微复杂一点的业务逻辑要求我们面对的必须是对象,而不是数据库,或者XML,又或者DataTable 等等.所以必须有一个从数据文件转换到对象的过程.这就是DAL真正的功能.而适应不同的数据源只是它其中的一项功能. 而不是说如果我们不用三层架构,就无法适应不同的数据源.
.cs 文件引用BLL中间的类.
我所认为三层架构，其实aspx的代码后置文件（cs）相当于controller，bll相当于action，而dal相当于service，dal里面调用静态的底层数据库访问方法。不知道这样理解对不对。不用ORM的情况下，应该是这样的吧，用了ORM可能bll会担负dal的一部分职能？
大家是怎么把查询条件从UI 传递到 DAL 的呢?
我是自学的，有可能是没做过大项目吧，对三层架构的理解也比较模糊。
我也在纳闷sql语句到底应该放在那一层。
例如:"select * from 表1"和"select * from 表2"
查询的时候都是用dataadapter填充datatable，返回datatable
但是如果这两条sql语句都放在dal层，那不是要定义两个方法吗？
那冗余代码不是很多吗？
说白了就是减少调用之间的耦合啦，不过mvc这方面做的不错。可以弄弄
UI，调用BLL处理逻辑；
BLL，调用DAL处理数据库；
DAL，处理数据库。
当然，中间应该有个IDAL接口，做多个DAL实现之，用来处理不同数据库
所有层中避免sql语句出现，玩玩存储过程，将需要的参数传到位 ok
怎样传递这个参数呢比如页面A 有  a,b,c 三个条件页面B 有 d,e 2个条件