• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DAtalayer design approaches

 
Derek Clarkson
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Recently I've been looking into datalayers for several applications because our systems here use a number of datasources and we may need to switch databases. The basic concept of keeping the data access in a single and seperate layer to the business logic (BL) and only allowing the BL to interact with it via methods calls seemed like a great idea. But I have hit a couple of issues I have not been able to resolve to my satisfaction.

The first is transactions and the second is prepared statements. Generally speaking a lot of methods in a datalayer assume a single access. For example reading a single record from a table or group of tables and returning the results to the BL. But I often want to do this as part of a larger block of processing and therefore do it using a prepared statement for speed. This is an issues for a datalayer because it is completely un-aware of what the calling method is up to and therefore cannot predict whether to use a direct SQL or create, store and use a prepared statement. Even if I added a parameter to indicate the use of a prepared statement, how does the datalayer know when I've stopped using it ? And doesn't persisting the prepared statement in between calls violate the basic concepts of a datalayer and how it should work ? Plus in order to do this we must also persist the Connection that created the prepared statement.

I've toyed with some ideas and the best I've come up with so far is for the datalayer to be programmed using prepared statements by default and to create additional methods which the programmer must call after he has finished the processing so the datalayer knows it can close off the prepared statement and associated connection. However I am not happy with this approach because it is an additional method that the programmer must can for no gain to his program and therefore is likely to be regularly forgotten.

I could also shift the management of the prepared statements and connections to the BL, but that violates the purpose of the datalayer from what I can see and really makes it a waste of time.

Any thoughts ?
Derek.
 
Adeel Ansari
Ranch Hand
Posts: 2874
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, just use prepared statement. Why you want to use the normal statement object?

Have you seen template for transactions.
One more related stuff: Unit of Work.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic