Hi,
I've looked into CSLA quite a bit with a view to doing some "real" development with it and think that, on the whole, it's a superb framework. The whole concept of using business objects to handle the business logic and then binding the interface to these, rather than datasets, really appeals to me.
I do, however, have one cause for concern and that's the way it connects to the actual database. The book (which I've read cover to cover) clearly advocates the use of stored procedures to perform the actual data access, the business objects themselves calling these procedures to effect the CRUD processes.
Now I don't have a problem with the insertion of data access logic into the business objects themselves, as has been discussed elsewhere, more that this system seems to tie you inexorably to a single, specific database. If, in the future, support for an alternate database was required, then in addition to rewriting all of the stored procedures for this additional database (assuming the RDBMS had such capabilities), the business objects would have to be altered and complicated to support multiple back-end databases.
To this end, has anyone used a system of database abstraction with CSLA.NET? I'm not necessarily talking about ORM systems like NHibernate here but rather a system of abstracting basic table access so that changes to the back-end database can be effected more easily?
I'd be very interested to hear about anyone's experiences in this area.
Many thanks,
Toby.
Hi,
Thanks for the reply. DLinq looks far too targetted at MSSQL right now to be a viable option I think. I've had a look at ORM products such as NHibernate and DevExpress's XPO but I'm not sure if going the whole ORM route is going to be more pain than gain tbh.
I've also recently started looking at RemObjects Data Abstract product and wondered if this might be of use but I doubt anyone here is using it yet.
I have to support Oracle and SQL Server so I had to do this a while ago.
There were many posts on this topic in the old forum. Not sure how many in this newer forum.
One basic idea is to use the interfaces for the data providers:
cn
As IDbConnectionI used a simple config switch to change a property that I called DbType to make the change from one to the other. The I coded my library (similar to the MS DAAB) to use this switch.
So I can execute a SQL statement against the correct DB and get back an IDataReader or some similar object and then use it in my BO.
Now that Oracle supports syntax like Inner Join the difference between it and SQL Server syntax has been reduced dramatically. My queries are well over 90% identical. For some I just add a test for the DbType and do a Replace:
.Replace(
"IsNull", "nvl").Replace("+", "||")This handles the large majority of the queries with syntax differences.
There are other (more complex) ways of doing this stuff but I like this straightforward approach.
Joe
Copyright (c) Marimer LLC