Transaction/connection control at the business layer?

Suppose I have 3 strong-typed entity objects (biz), each with their own corresponding data-layer objects. In those situations where I am to achieve a transactional result where all 3 must write to the database, how can I avoid violating layering-architecture principles by not having a biz controller object issue the same SqlConnection/SqlTransaction (or IDb interfaces) object to all 3 entities

Since only the data layer should be aware just how data access is implemented, how can I remove this awareness completely away from the biz layer, yet still attain transactions

Answer this question

Transaction/connection control at the business layer?

Sassenfeld
The good workable solution is to have a simple BizTransaction + Factory class designed with IDbConnection and IDbTransaction. It gets instantiated by the controller object and passed around to all transaction participants (biz -> da) and easily has them all execute their own set of statements to one commited transaction, with only the data layer classes ever knowing it's actually SqlConnection/SqlTransaction.
gfcgamer
I have been advised on ASP.NET architecture forum this is the wrong perception to layered architecture (as suspected). If anybody has references to working samples that demonstrate the good practice of transaction control across the layers, please do drop a link. Thanks.
Transaction/connection control at the business layer?

Answer this question