Asp.net 项目中事务处理放在哪一层?一般采用什么解决方法?

Question

在.net2005中,数据访问层就是DataSet,这里集中放各中SQL语句,
而连接字符放在config文件中!!
业务逻辑层是提取DataSet中的数据,并返回给表现层!!

Answer 1

如果你确定你将使用ado.net，那么你可以在业务层使用IDbTransaction这个接口，并且在DLL中一个静态全局方法用来Open这个IDbTransaction。例如你的业务逻辑代码可以写：using(IDbTransaction trans = OpenObjectsStorage())
{
    BLLMethodA(trans);
    BLLMethodB(trans);
}这样，每一个单独的方法使用参数trans进行同步，而不是自己创建单独的事务。

Answer 2

显然，你也可以自己定义同一个关于事务的接口，然后让所有BLL方法接受这个参数。这样的灵活性更大。不过如果迄今为止你还没有使用ado.net以外的数据库组件开发过商品化程序，那么使用一个过分抽象的接口可能会造成过分空洞的设计，所以可以以后再重构。对于大多数人，我觉得 IDbTransaction 已经是又高级又实用的设计了。

Answer 3

实际上，我上面说的有一点问题。public interface IDbTransaction : IDisposable
{
    void Commit();
    void Rollback();    IDbConnection Connection { get; }
    IsolationLevel IsolationLevel { get; }
}
这已经相当抽象了，而我还说“如果其确定你将使用ado.net”。从这个IDbTransaction 源代码来看，它也根本不是局限在ado.net的，可以代表我们能想到的所有事务的接口协议了。
至于说在逻辑层不出现事务接口，我觉得这是一个用OOP语言来行结构化编程的设计bug。如果不出现事务，就请不要在设计时讨论、担心事务问题。用一个bool来标记是否使用事务，从技术上只能说使用了一个随便干什么的bool标志变量，而不要谈论事务。如果必须用事务这个概念才能说明你使用那个bool变量的含义，那么你就应该对事务的职责协议使用代码来说明。说一我说，逻辑层一定会出现事务代码，那种认为事务是DAL的观点是自相矛盾的，又不想出现事务又想搞个什么隐喻的bool变量来代表事务，那是很诡异的、不具有准确逻辑意义的设计。

Answer 4

多数情况下，没必要直接和IDbTransaction接口打交道...使用System.Transactions就足够了...使用 System.Transactions 命名空间包含的类可以编写自己的事务应用程序和资源管理器。具体地说，可以创建和参与（与一个或多个参与者）本地或分布式事务。System.Transactions 基础结构通过支持在 SQL Server、ADO.NET、MSMQ 和 Microsoft 分布式事务协调器 (MSDTC) 中启动的事务，使事务编程在整个平台上变得简单和高效。它提供基于 Transaction 类的显式编程模型，还提供使用 TransactionScope 类的隐式编程模型，在这种模型中事务是由基础结构自动管理的。强烈建议使用更为方便的隐式模型进行开发。System.Transactions 也提供了一些可用于实现资源管理器的类型。使用 System.Transactions 基础结构的本机事务管理器可以有效地提交或回滚可变资源或单个持久资源登记。只能在 Windows 2000、Windows XP 和 Windows 2003 平台上使用此命名空间创建应用程序。

Answer 5

一般在BLL层里处理事务。System.Transactions是不错的选择，支持分布式，分库事务处理