Is it a good practice to implement Transactions in the Business Layer

We are looking at impleme开发者_如何学运维nting transactions in our ASP.NET web application. Its a three layered architecture. We are calling Web Services from the Business Layer and are planning to implement transactions in the Web service by setting the TransactionOPtion attribute.

Coming to the datalayer, is it a good option to implement transactions in the data layer or should I call it from the Business Layer. If I start the transaction from the Business Layer, I believe we will need to pass the transaction context to the Datalayer which according to me does not make sense since I can start the transaction in the Datalyer itself. I'm not talking to different Databases nor do I have multiple method calls from the BusinessLayer. So I dont think that we need to have transactions in the business layer in this context. Could you please verify/correct my understanding?

Thanks

Soni

If you have multiple calls to the data layer from one call to the business layer, I don't believe you can avoid elevating the transaction scope to the business layer.

If you restrict yourself to one data layer call per business layer call, then of course, you don't need business layer level transactions, and you can keep them only on your data layer.

It won't make it easy to track transactions.
Responsibility for opening and closing the transactions will move to the business layer.
-> The coupling between the layers will be far more than you would expect when you call a webservice.