Can I write my own DB independent Data Access Layer?

Can I write my own DB independent Data Access Layer?

Old forum URL: forums.lhotka.net/forums/t/10444.aspx


SultanKhan posted on Thursday, June 16, 2011

Dear,

I was going through the CSLA 3.8.4 ProjectTrackerWithObjectFactory. One thing I found is that when I use ProjectTracker.DalAdoFactory it requires a lot of DB specific code to be written. Like opeing the  SqlConnection, SqlTransaction and so on. Now if for some reason I need to change the DB from Sql Server to Oracle then I have to have make a lot of changes. (Actually my current DB is Oracle).

What I am planing is to write a seperate Data Access Layer which will handle all the DB nitty gritty so if the DB change I just need to change there.

My question is would it effect the core structure of CSLA like remote data portal and other stuffs? Would you please suggest how can I implement this without lossing a single advantage of CSLA?

Sincerely.

Sultan

 

RockfordLhotka replied on Thursday, June 16, 2011

Look at the current ProjectTracker code in svn (core/trunk) http://www.lhotka.net/cslanet/Repository.aspx

Or for more in-depth examples and discussion, get the Using CSLA 4: Data Access ebook from http://store.lhotka.net - I cover a couple ways to get clean separation between a pluggable DAL and the business classes.

SultanKhan replied on Saturday, June 18, 2011

Dear Rocky, When I am trying to download the repository from http://www.lhotka.net/cslacvs/viewvc.cgi/core/trunk/Samples/NET/cs/ProjectTracker I am getting error saying access is forbidden. Is there anything else I am missing?

I am using Tortoise SVN.

Thank You.

-- Sultan

 

RockfordLhotka replied on Sunday, June 19, 2011

The correct URL starts with svn:// http://www.lhotka.net/cslanet/Repository.aspx

SultanKhan replied on Monday, June 20, 2011

Thanks Rocky Smile

vschaak replied on Friday, June 17, 2011

Hi Sultan,

although a little outdated by todays standards, which are dominated by EF and the like, a few years ago I wrapped our data access code into one DAL that handles all that basic ADO stuff, so that our BO's are not in charge to deal with all that stuff. Even handling different DB's is not the biggest deal, so no change in the BO's, when switching from Oracle to SQL or vice versa.

In that case you'll have to deal with two (at least) core probs in your DAL:

different parameter naming convention (and be aware, Oracle doesn't simply replace the @ with a : ;check out the difference of passing parameters to a sproc or writing an ad hoc statement!)

SQL-Server nor DBProviderFactory know Oracles RefCursor. You'll have to make a workaround...

In my opinion it's only worth the effort when you really like the feeling of having wide control over what happens and like the idea of not having to much players in the game. Otherwise the mentioned EF and all that maybe a better solution.

Best wishes

V

SultanKhan replied on Monday, June 20, 2011

Thank You

Copyright (c) Marimer LLC