讨论贴:业务逻辑层\事务\存储过程,分层开发的选择!?
分层开发利于模块之间的解耦,一般常见的三层方式:UI层\业务逻辑层\数据访问层
这有个问题想和大家讨论学习,请高手们不吝指教:

当软件有较复杂的业务需求时,可以在数据库中编写存储过程,一个存储过程中去执行多个SQL语句.
但由于分层的需求,往往也可以在业务层编写方法去逐一调用数据访问层的多个方法
但如果需要事务处理时,就出现了问题,在数据库中编写存储过程来执行事务处理.这样做的话,业务逻辑层的存在就没有了价值,瘦业务逻辑层也使数据库服务器增大了负担,应用服务器仅仅成为了UI层的平台.
如果要把事务处理放到业务层的话,本人还不知道如何实现,DbTranscation的实例化是需要一个DbConnection对象的,按分层开发的解耦原则来说,这个不可行.

如果把事务处理放置到数据访问层去做的话,与直接写事务的存储过程没有区别,另外,同样也造成了瘦业务逻辑层.

其他,一句话综述:
为均衡数据库服务器与应用程序服务器,并且集中软件中的逻辑处理到业务层,如何在业务层进行事务处理.

当然,如果在数据层实现事务\或都在数据库编写事务存储过程,是否也合理,请有高见的谈谈.

还有一点,我思索的:很多程序喜欢用SqlHelper的方式去访问处理数据层,但有些数据层在创建Connection时,习惯为每一个数据库操作创建一个Connection,并且使用完后,立即关闭和释放Connection.这种方法是不可能提供给业务层事务处理的基础的..Net事务处理的基础就是在同一个Connection上执行多个数据库操作时,才能实现Commit或Rollback的.

话题比较大,讨论的重点还是在业务逻辑层实现事务处理?或是数据层实现事务?或是存储过程实现事务?若应该在业务逻辑层实现事务处理,应该如何完成?
------解决方案--------------------

引用:

但如果需要事务处理时,就出现了问题,在数据库中编写存储过程来执行事务处理.这样做的话,业务逻辑层的存在就没有了价值,瘦业务逻辑层也使数据库服务器增大了负担,应用服务器仅仅成为了UI层的平台

总是纠结这些干什么？

业务逻辑层就是让你按照业务需求来设计支持丰富表现层的数据操作接口，关键就是彻底屏蔽数据操作的细节，从而表现层绝对不需要再去纠结某种关系数据库语句。如果你翻来覆去地把在业务逻辑层设计中去纠结你的数据库，那么要分三层还有何意义？最终只会剩下“抄袭人家三层代码肯定有用”这种空洞的话，而不是自己确实需要。
------解决方案--------------------
connection和transaction由BLL层向dal层提供，dal类只负责操作数据，bll负责连接和事务的管理