CSLA Rewrite

tymberwyld posted on Thursday, June 21, 2007

I have rewritten the DataPortal classes to decrease the amount of objects needed for Data Access.  I've been using this for about 8 months now with no issues.  I'm pretty sure it will plug-in nicely with everything else in CSLA, but at this point, I have gone so far beyond CSLA that it might take some tweaking.

I got kind of tired of the Client vs. Server objects needed for DataPortals.  It's not really necessary.  Also, the DataAccess code had to be duplicated is all business objects and all business objects had to absolutely know what type of database was behind the scenes (Sql, Oracle, Access, etc.).  I have rewritten all base business classes and data access.  The DataPortal acts as a portal of communication as well a Data Access surrogate.  There is absolutely know data access code written in any business objects.

Here's the breakdown...

DataPortalFactory - handles initializing the correct type of DataPortal needed for the Application.  Simply add an <appSettings> element:  <add key="DataPortal" value="..." />.

Possible DataPortal types to put into the value are:

• Local, localhost, etc.
• Remoting Channel Url to the remotely hosted DataPortal: tcp://localhost:8080/DataPortal.rem
• WebService Url to the remote DataPortal:  http://localhost:4027/DataPortal.asmx
• WCF:  whatever the connection looks like for it - still in development

The classes needed to create DataPortals are greatly simplified.  Simply derive a class from IDataPortal.  There are two classes currently: 1.) DataPortal (which is used for both local and Remoting), and 2.) WebDataPortal which can be run as a WebService.  There is absolutely NO CODE required for the WebService!  Just create a new WebService project, add a Reference to the Dll, delete all code-behind files and replace the "Inherits" attribute of the WebService to point to the class in the Dll.

• IDataPortal - provides an interface which all DataPortals must implement
• DataPortal - Inherits from MarshalByRefObject and provides Local and Remoting Channel objects
• WebDataPortal - Inherits from a WebService and implements IDataPortal.
• WebDataPortalProxy - this is the only Proxy class needed and is only used for the WebDataPortal.  This may be able to become more generic to support multiple remote "Proxies", for example, WebService and WCF proxies may be able to be combined into one.
• WCFDataPortal - in progress...
  
• DataPortalContext - rewritten to support specifying which "connection" and data provider (System.Data.SqlClient vs. System.Data.OleDbProvider).
  

Here are some of the advantages:

1. There is no need for complicated config file settings.
2. Multiple Databases are supported through "context switching", meaning you can have multiple <connectionString> sections and the business objects can set the DataPortalContext before data access code is called.
   
3. DataPortals are not passed into business objects, rather, Business Objects are passed into DataPortals.  All Business Objects derive from IUpdateableObject.
4. There's no need for RunLocalAttributes or anything.  The DataPortal does not need to be location aware.
   

Disadvantages:

1. I still need to ensure that the DataPortal will function correctly with ServiceComponents and Transactions.

There are many other advantages to my library, it's almost a complete rewrite of CSLA but more simplified.  It includes DataMapping / ORM Mapping, Validation Rules, Strongly-Typed Business DataSet objects, simplified DataPortals, and Cryptography support (including an EncytableAttribute class which can be applied to any Property that needs encryption - and you can specify different ways to encrypt different properties).

I like using Strongly-typed DataTable, DataRows, and DataSets for business objects as well as sometimes using Business Object Classes themselves.  So, I have provided easy to use base classes for BusinessDataTable, BusinessDataRow, and BusinessDataSet.  These classes use Generics to simplify all the code so that derived classes only need to implement what DataColumns are needed.

Once I cleanup the code a bit more, I'll submit it if anyone is interested.  I am currently making it Framework 3.0 compatible.

gdk9am replied on Thursday, June 21, 2007

Hi

Yes I would be interested in seeing your code especially with regard to datasets, datatables, and datarow

 

tymberwyld replied on Friday, June 22, 2007

Let me clean up some code and add a sample Project to get you started and then I'll upload it.  Look for it in about a week (as I have other stuff to do during the day )

RockoWPB replied on Wednesday, June 27, 2007

Would really like to see it especially with the 3.0 support for WPF and the dataset stuff sounds really interesting too.