讨论贴:业务逻辑层\事务\存储过程,分层开发的选择!?

过眼云烟Davils 2010-11-08 04:04:15

加精

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

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

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

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

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

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

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

...全文

2136 94 打赏收藏转发到动态举报

写回复

用AI写文章

94 条回复

切换为时间正序

请发表友善的回复…

发表回复

zhqchd 2013-05-16

打赏
举报

很有深度,慢慢琢磨下.

f327869853 2013-05-12

打赏
举报

89 90 91 基本可以解决问题，这个事务类写的有点厉害

面向对象的猫 2013-04-28

打赏
举报

如果是 asp.net 的項目的話，可以用到asp.net頁面級別事務，

fishinthewindext1 2013-03-27

打赏
举报

DAL中的方法调用DBContext 中封装的方法如ExecuteNonQuery，或ExecuteReader去执行数据访问操作

fishinthewindext1 2013-03-27

打赏
举报

上面的DBContext 类放在 DAL 中，在BLL中调用，如： _dbContext = new DBContext(svnlib); _changeDAL = new ***DAL(_dbContext); try { _dbContext.BeginTransaction(IsolationLevel.ReadUncommitted); 业务逻辑 _dbContext.Commit(); } catch (***Exception) { _dbContext.Rollback(); throw; } catch (Exception e) { _dbContext.Rollback(); }

fishinthewindext1 2013-03-27

打赏
举报

using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Data; using System.Data.Common; using Microsoft.Practices.EnterpriseLibrary.Data; namespace SVNGo.DAL { public class DBContext { private Database _db = null; private DbTransaction _transaction = null; private DbConnection _conn = null; private int _transactionRef = 0; public static DBContext CreateDBContext(string connName) { return new DBContext(connName); } public DBContext(string connName) { _db = DatabaseFactory.CreateDatabase(connName); } public void BeginTransaction(IsolationLevel isolevel) { if (_transaction != null && _transactionRef > 0) { ++_transactionRef; } else { _conn = _db.CreateConnection(); _conn.Open(); _transaction = _conn.BeginTransaction(isolevel); ++_transactionRef; } } public void Commit() { if (_transaction != null && _transactionRef > 0) { --_transactionRef; if (_transactionRef == 0) { _transaction.Commit(); _transaction = null; if (_conn != null && _conn.State == ConnectionState.Open) { _conn.Close(); _conn = null; } } } } public void Rollback() { if (_transaction != null && _transactionRef > 0) { _transaction.Rollback(); _transactionRef = 0; _transaction = null; if (_conn != null && _conn.State == ConnectionState.Open) { _conn.Close(); _conn = null; } } } public DbCommand GetStoredProcCommand(string storedProcedureName) { return _db.GetStoredProcCommand(storedProcedureName); } public void DiscoverParameters(DbCommand dc) { _db.DiscoverParameters(dc); } public int ExecuteNonQuery(DbCommand dc) { if (_transaction != null) { return _db.ExecuteNonQuery(dc, _transaction); } else { return _db.ExecuteNonQuery(dc); } } public DbDataReader ExecuteReader(DbCommand dc) { DbDataReader dr = null; DataReaderWrapper drw = _db.ExecuteReader(dc) as DataReaderWrapper; if (drw != null) { dr = drw.InnerReader as DbDataReader; } return dr; } } }