Hi everybody, i'm going to develop a new application and i have been reading & studying the csla framework, i have to take a decision about using or not the csla framework but i haven't covered the data access layer of the framework so i would like to take just the business objects and override the data access methods of the business objects to implement my own data access layer, would be any problem if i do this?, are there some special things that i must to consider to work in this way?
well, thanks in advance.
Most of us have some sort of DAL so that we do not have to code the raw ADO.Net statements over and over again.
After I wrote mine I noticed that it closely matched the MS DAAB so I felt comfortable with the code. The DAAB is a fine block of code to use.
It allows you to write very simple code in your DataPortal_XYZ methods.
Joe
Hi Joe
I'm curious to see how they look, would you mind posting a sample?
Thanks
Just download the MS DAAB to see how it is built.
It has many overloads for each of the methods so you have a ton of flexibility in how to call it.
e.g.
dr = New SafeDataReader(DAL.ExecuteReader(cn, "SomeSP", prm))
Above is a call to my DAL to get a data reader.
I pass in the connection and SP name and a pararm array.
The DAL takes care of attaching the parameters.
Other overloads include passing a connection string or a transaction.
Or a SQL String or ....
Joe
Thanks Joe
What version of MS DAAB are you using? I donwloaded 'Enterprise Library May 2007.msi' yesterday. I presume I don't need the whole Enterprise Library just the DAL?
Ozi
There's no reason to write your own CRUD code or DAL anymore -- you can just generate one. There is a wide selection of both freeware and commercial products.
We started out looking at some free OR Mappers (which can do much more than just CRUD, but also can provide a good basic DAL). Currently, we have CSLA bolted onto a DAL layer based on the Wilson ORMapper and Welter CodeSmith templates. NHibernate is another good mapper. (Some would argue the mappers are overkill, but both of these support a large number of different databases from the same DAL)
As far as Microsoft technology (e.g. LINQ), it's a fair bet that anything Microsoft does DAL-wise will (1) be biased toward Microsoft products (e.g. SQL Server), and (2) will change in the future -- anyone remember DAO? ADO 1.0?. So, I advise putting a layer between you and anything Microsoft specific to insulate you from future changes.
rsbaker0:
As far as Microsoft technology (e.g. LINQ), it's a fair bet that anything Microsoft does DAL-wise will (1) be biased toward Microsoft products (e.g. SQL Server), and (2) will change in the future -- anyone remember DAO? ADO 1.0?. So, I advise putting a layer between you and anything Microsoft specific to insulate you from future changes.
(1) DLINQ currently is Microsoft biased only supporting Sql Server. I believe they have opened the door for vendors to write their own libraries, but I wouldn't expect support for other databases until some time after .Net 3.5 comes out.
(2) This is true for ANY product, not just Microsoft.
Copyright (c) Marimer LLC