So many ways, so little time
Currently working on my VSLive all day .NET Data Access: Soup to Nuts workshop. Andrew Brust and I will be presenting this on July 31st at the VSLive Conference in New York.
It got me thinking. With .NET, Microsoft gives you so many ways to work with transactions. You can:
- Program against DTC yourself (and you have to be crazy to do this)
- Use Enterprise Services
- Use ADO .NET Transactions
- Use TSQL Transactions
So many transactions, so little time. Well you would never want to use DTC. Period, there is just way too much pluming to deal with. Working with Enterprise Services and creating Serviced Components is quite compelling. There is a fair amount of work involved, so it is only really good when you need a two-phased commit across multiple data sources.
Then there is ADO .NET. Not sure why you would ever want to do this either. The SQLClient transaction object is worthwhile, but you would be better of (even if you want to deal with isolation levels) doing your transaction in TSQL. Maybe I am biased against lots of logical code in ADO .NET and rather place the transaction processing inside the TSQL for performance and maintenance reasons. I think that lots of transaction code in ADO .NET leads to very fat code that is also very verbose for no reason. Your middle tier should be thin and fast. Your database is better equipped to handle the transaction. Since ADO .NET limits to one connection, the two are almost the same thing. Now there is always an exception. There are times when ADO .NET is appropriate, I am just searching for it. :)
3:56:07 PM 
|
