Should I use EF with CSLA?

Should I use EF with CSLA?

Old forum URL:

JonM posted on Thursday, June 06, 2013

It seems like EF is all the rage these days.  I'm just starting to play with it myself.  After getting bitten by that LINQ-to-SQL disaster I wanted to wait to see if this technology was going to make it.  Anyway, EF seems to make it fairly easy to model your business classes.  Does this technology replace CSLA?  With data annotation we get rudimentary business rules.  Should I just use straight EF or should I wrap EF entities with CSLA objects?  It seems like double work re exposing all of those props again in CSLA.  I've used for years now.  Traditionally my dataportal methods talk straight to sql server.  I've played with a couple of projects where we exposed data through a REST web service and the CSLA classes were modified to make http calls running the dataportal in 'local' mode.  Anyway, I'm just reaching out for guidance and opinions on this.

JonnyBee replied on Thursday, June 06, 2013

Some questions to add to the checklist

And probably more questions that should be answered.

I regard EF as primarily a data access technology and the come and go quite often from Microsoft.

So for my preference - I like the CSLA coding style, business objects and rule engine and the fact that my code can run on number of platforms with a minimum of change.

EF and corresponding tooling in Visual Studio is very nice in a Web application and if you only need the DataAnnotation rules (or add custom code these in the Postback).

JonM replied on Monday, June 10, 2013

It seems like EF is a big piece of infrastructure to learn, understand and maintain just to use as a back end for CSLA.  Seems like there is a lot of duplicate work.  It seems like you would either just use EF or use CSLA with a regular backend.  Am I wrong?


RockfordLhotka replied on Monday, June 10, 2013

I often use EF to create my DAL behind CSLA objects. I use model first, because I am using EF to make it easier to create the DAL and I don't really want or need specialized entity types. The reason for using EF like this is that it is often simpler than hand-crafting raw ADO.NET code.

On the other hand, if you are good and hand crafting that code, or are using automation (like codesmith) to create the ADO.NET DAL code, then I wouldn't necessarily use EF.

Copyright (c) Marimer LLC