在存储过程中 Begin TRANSACTION Commit TRANSACTION ROLLBACK TRANSACTION 或 using (TransactionScope transScope = new TransactionScope()) {} 业务层中可以不用connection. 可以在dal中声明一个属性来包装DbTransaction, 然后bll中可以得到. 对于要用事务的方法传同一个DbTransaction即可
To wuyq11: 首先谢谢你的回复. 我知道代码怎么写,关键是我要知道我说的那种情况,应该由哪方来做这件事,主要是讨论一种写代码和存储过程的规范. 因为如果存储过程里都是没写事务的,那就意味着程序中调的地方都要加上类似 using (TransactionScope transScope = new TransactionScope()) {} 的语句,而我觉得应该存储过程应该管好自己内部的事务,程序要管好的是自己多次调用之间的事务.
To vrhero: 我仅指过程对自己内部做的事的处理.譬如过程里有两个Update语句，执行第一个没有问题，当执行第二个的时候发生错误。这时候对一个update的回滚是应该存储过程做，还是返回一个错误，由调用者判断，然后回滚呢。 我理解为一个方法应该自己做好自己的事情，自己内部已经出错了，不处理回滚，而依赖调用者，是不是有点不合理？
Begin TRANSACTION
Commit TRANSACTION
ROLLBACK TRANSACTION
或
using (TransactionScope transScope = new TransactionScope())
{}
业务层中可以不用connection.
可以在dal中声明一个属性来包装DbTransaction,
然后bll中可以得到.
对于要用事务的方法传同一个DbTransaction即可
首先谢谢你的回复.
我知道代码怎么写,关键是我要知道我说的那种情况,应该由哪方来做这件事,主要是讨论一种写代码和存储过程的规范.
因为如果存储过程里都是没写事务的,那就意味着程序中调的地方都要加上类似
using (TransactionScope transScope = new TransactionScope())
{}
的语句,而我觉得应该存储过程应该管好自己内部的事务,程序要管好的是自己多次调用之间的事务.
我仅指过程对自己内部做的事的处理.譬如过程里有两个Update语句，执行第一个没有问题，当执行第二个的时候发生错误。这时候对一个update的回滚是应该存储过程做，还是返回一个错误，由调用者判断，然后回滚呢。
我理解为一个方法应该自己做好自己的事情，自己内部已经出错了，不处理回滚，而依赖调用者，是不是有点不合理？
上面的第一种是指在存储过程中控制事务，第二种是指在ADO.NET中控制事务
算了，程序里加上事务吧。
不过我还是觉得不合理，本来存储过程自己可以做的事，现在所有调用的地方都得先开始事务-〉调用过程-〉结束事务，工作量明显增加。作为公用方法，调用的地方肯定不止一个。
至少我看到SqlServer里的系统存储过程都会有事务去处理自己对库的改变的，不知道其他数据库是不是这样。