Data Access Architecture

Data Access Architecture

• Sweeps78

  Thank you for the inputs. However, I am not quite able to grab the idea. In my thought, I am looking for some kind of solutions like MVC. My friend give me some ideas on how easy to work with MVC using Java. However, I can't find such equivalent in MS.
  
  
  

• Juliusz

  Graham,

  Your approach seems to be excellent in handling the transaction issues.However as you have used a very high level architectural nomenclature, it is somewhat difficult for me to understand.

  Can you please provide some sample code over here to support your answer as to what exactly is to be written in business layer what in webservice(i presume facade means webservice) if any and what in data access.

  It will help us in understanding it in a more practical sense.

  regards

  
  

• S Nesbitt

  You are absolutely right. This question has come up for me a number of times, so being that I wrote my previous response in a hurry, I have decided to post a more detailed example on my blog:

  http://grahamsibley.typepad.com/thoughtfactory/2007/01/abstracted_data.html

  I hope this provides you with the code samples you are looking for. ; )

  - Graham

  
  

• rodniko

  Another approach you can look at is to have single class which is designed to traverse through your object model, collect the command statements to execute, and then execute them all in a single transaction. This way, all of your data processing and transaction handling exists in a single location. It would look something like the following:

  1) Facade.Save(myObject)

  Called by consuming applications and passes in the object to save.

  2) ObjectSaveVisitor.Visit(myObject)

  Called within the Facade.Save method. Collects all commands to execute. Traverses through the object hierarchy, collecting commands for each object.

  3) CommandProcessor.Commit()

  Called within the Facade.Save method. Executes the collected commands within a single transaction. Abstracts all transaction and command execution logic from the other layers.

  In this scenario your business objects do not need to have any transaction logic, nor does your facade layer. However, your facade layer can still implement transactions for specific business processes and the CommandProcessor in the example would simply participate in the parent transaction.

  Just another item for your toolbox. ; )

  
  

• i7hira7

  Graham,

  Your approach seems to be excellent in handling the transaction issues.However as you have used a very high level architectural nomenclature, it is somewhat difficult for me to understand.

  Can you please provide some sample code over here to support your answer as to what exactly is to be written in business layer what in webservice(i presume facade means webservice) if any and what in data access.

  It will help us in understading it in a more practical sense.

  regards

  
  

• Strandberg

  Hi cwlaualex,

  Trasaction management should be done seperately inside the business layer using the new namespace System.Transactions and put everything inside the transaction scope.

  One more thing, try to take out the business logic out of DAL layer as then we loses its basic purpose.

  Manager class can be added but it would just serve the purpose of adding one more layer of abstraction for transactionscope , as we have already set the database related code in typed dataset and custom objects and business requirement can't be the same.

  This is regardless of whether you are using Typed datasets or custom databsae entities to fetch and manipulate the data.

  For more on this , you can see the following posting

  http://www.codeproject.com/cs/database/dac2.asp

  Hope this helps.

  Regards

  
  
• Data Access Architecture