I am new to CSLA and Entity Framework. I am creating a new CSLA / Silverlight application that will replace a 12 year old Win32 C++ system. The old system uses a custom DCOM business object library and uses ODBC to get to SQL Server. The new system will not immediately replace the old system -- they must coexist against the same database for years to come.
At first I thought EF was the way to go since it is the latest and greatest. After making a small EF model and only 2 CSLA editable root objects (I will eventually have hundreds of objects as my DB has 800+ tables) I am seriously questioning the use of EF.
In the current system I have the need many times to do fine detail performance tuning of the queries which I can do because of 100% control of generated SQL. But it seems in EF that so much happens behind the scenes that I lose that control. Article like http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html don't help my impression of EF.
People seem to like EF because of LINQ to EF but since my criteria is passed between client and server as criteria object it seems like I could build queries just as easily without LINQ. I understand in WCF RIA that there is query projection (or something like that) where I can do client side LINQ which does move to the server before translation into actual SQL so in that case I can see the benefit of EF, but not in CSLA.
If I use raw ADO.NET, will I regret my decision 5 years from now?
Has anyone else made this choice recently and which way did you go?
Well, you are describing almost the exact same scenario we faced a little over 2 years ago (even down to our C++ application being 12 years old at the time and the old and new versions of the software needing to co-exist for several years). We too also needed control over the generated SQL.
We evaluated several commercial products (LLBLGen Pro and DevExpress XPO), and two open source Object Relation Mappers -- NHibernate and the Wilson ORMapper. EF didn't exist at the time. Our application has several unique requirements -- we support SQL Server, Oracle, and MS Access, customers can add their own custom fields (and tables) to the schema, sometimes they choose to widen string columns to allow more data, and we also have our own concurrency model for detecting collisions (only changed values are examined versus a timestamp or all columns).
It turned out both NHibernate and the Wilson ORMapper could meet our requirements, but we ultimately went with the Wilson ORM because it is much smaller and easier to work on (and also supports completely native ad hoc SQL while NHibernate has it's own dialect). Both of them also support paging when dealing with very large result sets, and this has turned out to be a critical benefit. (It's pretty cool to open a grid on table with a million rows in a second or so and be able to scroll all the way through it with reasonable response time). We don't use anywhere near the full ORM capabilities but instead are leveraging it for it's ability to generate SQL that we have some control over.
The great thing about CSLA is that it is almost completely agnostic about whatever data access you want to use, so you can bolt it on top of practically any lower level framework.
I think you have several good choices. I don't have any experience with EF, but I'd suggest you choose a path that lets you use code generation to produce your low level DAL. (We use CodeSmith and have modified the templates extensively). I don't think the Wilson ORM has a wide following but NHibernate is very popular and you might take a look at it.
rsbaker0 , thanks for your input. I really appreciate it.
I just finished watching Rocky's core video on where to put the DAL (in the DataPortal_xyz, in another assembly called by DataPortal_xyz, or in object factory). I really like solution #2 the best but it means that I cannot really have a pluggable DAL without using a common interface between various choices like EF or raw ADO.NET. Lots of things can be exposed through IDataReader but I don't think EF is well suited to IDataReader even though there is a IDataReader wrapper for EF on codeplex.
I will look into other ORMs like NHibernate. I also haven't yet looked into the CodeSmith templates but I need to as soon as they come out with v4 versions.
Thanks.
Hello,
We are currently reviewing Silverlight 4.0 and .NET 4.0 template patches that were contributed. An individual in our forums is currently looking at implementing Entity Framework 4 (EF4) support.
Thanks
-Blake Niemyjski
Entity Framework is good data access option. You have one layer of abstraction over database, so in your case when using existing database, you can model data access layer in order to fit better to a business layer. I suggest you to check our open source project for generation of CSLA classes from an EF model: http://t4csla.codeplex.com/
Copyright (c) Marimer LLC