Future of CSLA with MS Entity Framework v2

martin_s posted on Sunday, May 10, 2009

We are currently researching the migration of a large system into .NET  A project lasting several years on their core business system.  The system will be N-Tier architecture so object state across the tiers is a vital part of the application framework.  The customer has internal developers and although our company will perform all the development of the core system their developers will consume some of the services we will publish.  The customer ultimately has the final decision on the development environment.  A decision which will be based largely on the recommendations made by ourselves, but with some input from their own developers.  They are obviously looking to be as future proof as possible with the amount of financial investment required for the project and as such are keen on sticking close to Microsoft - which leads us to the Entity Framework.

I appreciate that at the moment the EF is basically just an OR/M and CSLA and EF perform two different tasks.  Indeed it would be possible to use CSLA and EF together if required.  However, reading details of EF v2 for VS10 it seems that EF v2 begins to offer the same mobile objects/Object state management functionality of CSLA

http://blogs.msdn.com/efdesign/

I know noone has a crystal ball, but as MS say that when released EF v2 will be their preferred mechanism for database application development.  Will this see CSLA struggle to maintain a place in the development environment and maybe see development/support of the CSLA framework cease.

There is no disrespect or negative tone implied to CSLA by this post.  My technical papers presented to the customer to date have identified it as an excellent choice of application framework.  Stable, well designed, feature rich and would be an excellent choice for the system development.  However at the customers request on investigating MS EF I have to perform a risk assessment on the choice of CSLA at this point in time with the announcement of the features in EF v2.

I appreciate your comments
Martin.

JoeFallon1 replied on Sunday, May 10, 2009

Some comments:

1. I have used CSLA for 5 years and Rocky has always kept it on the leading edge of technology. It has been improved tremendously since version 1.0.

2. I am not very familiar with EF. But I am familiar with MS practices. Soooo - current version is v1.0. At least it is not vaporware. V2 will be better but still have large holes in it. V3 will be pretty darn good.

But I am not sure you can wait until v3 comes out.
So I vote for CSLA.

Joe

RockfordLhotka replied on Sunday, May 10, 2009

Assuming EF 2 achieves the goals around the use of POCOs, it should play better with CSLA than today. If not, then we'll have to wait for EF 3 to really get there. Time will tell, but history indicates that version 3 of a product is when it gets really good.

The thing to remember is that EF does something very different from CSLA, and visa versa. EF 2 doesn't change that - it just opens up better ways for EF to interact with other frameworks and models (such as CSLA).

EF is a data access technology. CSLA is a business layer creation technology. They really don't focus on the same things at all.

Now if you told me that EF was going to get data binding support, formalized business/validation/authorization rules support, n-level undo support and support for n-tier distributed models so you could switch between 1-, 2-, 3- and 4-tier physical deployments with no change to your UI, business or data access code - then it would seem like CSLA had no value.

But that's not what is happening. What is happening is that EF is gaining the ability to persist data from POCOs, and if they do this right, it could mean EF can persist data from things like CSLA objects. That would be very cool!

In fact, the reason the ObjectFactory concepts were added in CSLA 3.6 is in anticipation of EF gaining these capabilities. If Microsoft gets it right, CSLA should be able to include a pre-build ObjectFactory implementation that leverages EF to persist CSLA objects directly - thus radically reducing the amount of code you need to write to create a DAL (assuming you like the code generated by the EF designers).

But in the end, we won't know how EF 2 will play out until it gets closer to release and we see exactly how flexible the POCO support is.

martin_s replied on Monday, May 11, 2009

Thank you for the responses.