在三层架构中在哪一层使用事务合理?
0
悬赏园豆：10
[已关闭问题]
我认为在业务层进行事务控制比较好.这样做的好处是数据访问层的方法粒度都很小,基本上就是增删改,方法重用度高.
如果被事务放在数据访问层,那数据访问的方法的重用度就低了,除非方法参数中增加一个事务参数
其他回答(7)
0
本来就在业务层啊 在业务层回滚后 数据层会跟着回滚的
0
数据层有数据层的事务，业务层有业务层的事务。我觉得这两点不大能等同。
因为可能会遇到：一个业务层操作涉及到一系列的数据库操作，而业务层不应该知道这个操作是有事物控制的。那么这样的“事务”就应该仅限于数据层。
0
业务层
1
要根据情形而定了，写在业务层一般重用的是数据层的例如增、删、改方法，这个方法本身重用度会很低。如果写在数据层的话，有些情况考虑不到，又必须在业务层重写一个单独的事务处理。用过sqlHelper的会知道，它提供了简单的事务处理。
0
事物应该写在数据库里。
0
数据事务肯定是在数据层、
首先分层的意义在哪里？...在于它带给应用程序以灵活的部署、可维护性。在开发过程中分块的处理各个功能，可以提高开发效率。
如果在事务上不写在数据层，如果涉及数据的回滚，那么你在两个数据库版本的系统中，怎么处理这，问题就来了。在数据层中用事务的话，我直接用相对应的数据库版本实现文件来实现就行了，而逻辑层面没有改动。如果写在其他的地方，你就得把数据层外的其他层面，再写一个不同版本的实现。
这样的话，还用分层干吗？，直接两个版本的系统得了。所以，提高维护性，代码充用性，就是写在数据层。
想指教一下，如果一个业务功能涉及到多个Dao的交互，例如inertHeader(),inertDetails()。按你把事务写在数据层，如果inertHeader()成功了，它内部事务没错，comit成功，然后inertDetails()抛异常，回滚，但只能影响到自身我一下的代码，对于inertHeader()没影响。而放在业务层，可以很好地控制一个功能的事务完整，不过正如你所说，这样就耦合很大了，唯一做法就是写一个人事务接口去解耦，不过我觉得还是不合理，请指教一下。
一般情况下使用事务的逻辑都是相对复杂的。我所说的数据层、只是说把涉及特例数据库〔例sqlserver〕的事务对象的实现都要封装到数据层。在逻辑层使用事务的时候调用封装特定数据库操作类的事务实现方法。在逻辑层使用事务有时候不可避免的，那么就只能是尽可能的将面相的事务对象抽象化，达到面相事务、而不是面相特例数据库事务的目的。避免在逻辑层声明SqlTransaction的对象。完全可以是声明currDB.DBTransaction〔curr为封装的一个依赖配置文件的实体〕
0
通常是有DAL(Data Access Layer) 和 BLL(Business Logic Layer)。 事务管理层应该在BLL层。在开发的时候一般把这两个层从WebSite里分离出来，以Library形式管理，这样可以减轻WebSite的负担。但是由于硬件设备和网速的发展，把这两个层方在App_Code里面，以Class形式管理也无所谓。
0
数据访问层。
你得让回滚和业务层没关系，业务层只负责调用回滚的那个。
