Question

How would you go about calling several methods in the data access layer from one method in the business logic layer so that all of the SQL commands lived in one SQL transaction?

Each one of the DAL methods may be called individually from other places in the BLL, so there is no guarantee that the data layer methods are always part of a transaction. We need this functionality so if the database goes offline in the middle of a long running process, there’s no commit. The business layer is orchestrating different data layer method calls based on the results of each of the previous calls. We only want to commit (from the business layer) at the very end of the entire process.

Answer 1

well, firstly, you’ll have to adhere to an atomic Unit of Work that you specify as a single method in your BLL. This would (for example) create the customer, the order and the order items. you’d then wrap this all neatly up inside a TransactionScope using statement. TransactionScope is the secret weapon here. below is some code that luckily enough I’m working on right now :):

public static int InsertArtist(Artist artist) {     if (artist == null)         throw new ArgumentNullException('artist');      int artistid = 0;     using (TransactionScope scope = new TransactionScope())     {         // insert the master Artist         /*             we plug the artistid variable into             any child instance where ArtistID is required         */         artistid = SiteProvider.Artist.InsertArtist(new ArtistDetails(         0,         artist.BandName,         artist.DateAdded));          // insert the child ArtistArtistGenre         artist.ArtistArtistGenres.ForEach(item =>         {             var artistartistgenre = new ArtistArtistGenreDetails(                 0,                 artistid,                 item.ArtistGenreID);             SiteProvider.Artist.InsertArtistArtistGenre(artistartistgenre);         });          // insert the child ArtistLink         artist.ArtistLinks.ForEach(item =>         {             var artistlink = new ArtistLinkDetails(                 0,                 artistid,                 item.LinkURL);             SiteProvider.Artist.InsertArtistLink(artistlink);         });          // insert the child ArtistProfile         artist.ArtistProfiles.ForEach(item =>         {             var artistprofile = new ArtistProfileDetails(                 0,                 artistid,                 item.Profile);             SiteProvider.Artist.InsertArtistProfile(artistprofile);         });          // insert the child FestivalArtist         artist.FestivalArtists.ForEach(item =>         {             var festivalartist = new FestivalArtistDetails(                 0,                 item.FestivalID,                 artistid,                 item.AvailableFromDate,                 item.AvailableToDate,                 item.DateAdded);             SiteProvider.Festival.InsertFestivalArtist(festivalartist);         });         BizObject.PurgeCacheItems(String.Format(ARTISTARTISTGENRE_ALL_KEY, String.Empty, String.Empty));         BizObject.PurgeCacheItems(String.Format(ARTISTLINK_ALL_KEY, String.Empty, String.Empty));         BizObject.PurgeCacheItems(String.Format(ARTISTPROFILE_ALL_KEY, String.Empty, String.Empty));         BizObject.PurgeCacheItems(String.Format(FESTIVALARTIST_ALL_KEY, String.Empty, String.Empty));         BizObject.PurgeCacheItems(String.Format(ARTIST_ALL_KEY, String.Empty, String.Empty));          // commit the entire transaction - all or nothing         scope.Complete();     }     return artistid; } 

hopefully, you’ll get the gist. basically, it’s an all succeed or fail job, irrespective of any disparate databases (i.e. in the above example, artist and artistartistgenre could be hosted in two separate db stores but TransactionScope would care less about that, it works at COM+ level and manages the atomicity of the scope that it can ‘see’)

hope this helps

EDIT: you’ll possibly find that the initial invocation of TransactionScope (on app start-up) may be slightly noticeable (i.e. in the example above, if called for the first time, can take 2-3 seconds to complete), however, subsequent calls are almost instantaneous (i.e. typically 250-750 ms). the trade off between a simple point of contact transaction vs the (unwieldy) alternatives mitigates (for me and my clients) that initial ‘loading’ latency.

just wanted to demonstrate that ease doesn’t come without compromise (albeit in the initial stages)