So I have pulled my transaction scope into an aspect/policy. I want to associate a database connection, just one, with this transaction scope before calling the method (a data access method) in the pipeline which will call one or potentially more CRUD related and or nested methods.
I could do this by injecting, as one of the input arguments in the call handler, a database connection which I want to use. This does, however, add tight coupling between the attribute and its target method, which is plain naughty.
I could refactor the data layer to ensure that any nested calls (to the same connection) are un-nested and sequential (ensuring that when using SQL Server 2008 and a transaction scope this doesnt escalate to a distribtuted transaction).
Another alternative might be a connection factory which serves up a connection but leaves my business layer agnostic to the underlying connection type. IDBConnection could do this. A couple of other thoughts are subclassing TransactionScope (by adding in specific one connection capability to it, which is next to "re"-useless elewhere), A global/static data connection object, which is frowned upon or jsut simply threading through the dataconnection object I want to share amongst the methods I am working with within the transaction.
The rationale behind all of this is that I want a clean way of wrapping a method or set of methods which are reliant upon a single database connection without incurring the wrath of MSDTC and to avoid using a static connection object, if at all possible.
