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?
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.
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.
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.
Copyright (c) Marimer LLC