Time to abandon LINQ to SQL in favour of Entity Framework?

Time to abandon LINQ to SQL in favour of Entity Framework?

Old forum URL: forums.lhotka.net/forums/t/8864.aspx


Russ posted on Saturday, May 01, 2010

I notice that the Collective sample from the VS2010 launch uses Entity Framework (EF).  I have been reading for some time that MS was putting effort into EF and not LINQ to SQL (L2S). I have also read that L2S was better than EF in many ways.

I am about to rewrite a CSLA 3.7 line of business WPF application in CSLA 4.0 and wanted to know if it is time to abandon L2S in favour of EF?

RockfordLhotka replied on Saturday, May 01, 2010

I'm slowly migrating all the demos to use EF. ProjectTracker is the tough one because of its previous reliance on stored procedures (which are still hard to use in EF). But by the time I'm done with updating all the demos they won't be using L2S anymore.

dec698 replied on Wednesday, May 26, 2010

Hi Rocky,

I was just wondering if do you have a timetable for this PTracker sample app to be ported to EF, I'm interested to see how its "properly" done (ported correctly) considering the way the current design of PTracker.

Thanks!

JonnyBee replied on Thursday, May 27, 2010

Hi,

If you are interested in using ObjectFactory have a look at the ProjectTrackerWithObjectFactories sample for Csla 3.8.
This sample provides a "plugable" ObjectFactory using either raw ADO, L2S or EF (all for .NET 3.5) 

dec698 replied on Thursday, May 27, 2010

Thanks Jonny,

In the book itself the discussion revolves around L2S mainly, would it be possible for you or anybody to point me to a resource where I can learn more about ObjectFactory and stuff so I can successfully develop a system built around EF. (or maybe its implementation to PTracker sample app)

Thanks for your time!

dec698 replied on Thursday, May 27, 2010

Is this assumption of mine correct base on Jonny's statement:

To use EF I need to get my head around ObjectFactory?

RockfordLhotka replied on Thursday, May 27, 2010

dec698

Is this assumption of mine correct base on Jonny's statement:

To use EF I need to get my head around ObjectFactory?

No, that is not true. You can use EF from DataPortal_XYZ methods as well.

There are actually four data access models you can use with CSLA:

  1. DataPortal_XYZ direct to data source
  2. DataPortal_XYZ to abstract DAL
  3. ObjectFactory direct to data source
  4. ObjectFactory to abstract DAL

I walk through all four of these in the Core 3.8 video series.

Jav replied on Thursday, May 27, 2010

Certainly in coming up with .Net Framework, WPF, WCF,  and advances in languages, etc Microsoft has done a marvelous job.  It has made it possible for us to create better and significantly more sophisticated apps a whole lot faster. 

But when it comes to database access, I am not sure that promoting every 6 months some new fangled technology that does the same old thing is exactly in the interests of the programming communilty.  All it does is waste our time learning it - only to discard it in favor of something slightly different a few months later. So now, to use EF one has to do away with stored procs! 

I'll bet that after I spend months dismantling my hand crafted SPs to plug in the EF, I'll find that things are neither faster nor easier - nor will I see any flowers blooming where there were weeds before.  But as sure as the sun come up every morning, by that time Microsoft will already be in the process of replacing the EF with FU.

Jav

RockfordLhotka replied on Thursday, May 27, 2010

When I talk about data access, I always point out that the only technology that has remained mostly consistent over the past 15 years is the raw ADO model (connection, command, datareader, parameter objects). If you want to build a DAL that you'll never have to change in any major way, you should use raw ADO.NET.

If you want the productivity and abstraction benefits of any other technology (DataSet, LINQ to SQL, EF, etc) then you must face the cold, hard reality that your DAL code will become obsolete by "the next great abstraction" within a few years.

The DataSet is amazing, in that it has lasted about 8 years with no major changes - that's unprecidented. But the DataSet is (imo) at the end of its life (it doesn't exist on Silverlight, can't work well with oData, etc).

The most we can hope for is that EF 4 becomes a stable base for the next 8 years - but I don't think EF 4 is mature enough for that. Maybe EF v.next will be mature enough... Certainly EF is Microsoft's strategic technology choice right now, so it is as good a bet as you can take - but I still very much doubt we'll go from EF 4 to EF v.next without some significant changes and issues.

Jav replied on Thursday, May 27, 2010

Rocky,

I totally buy what you you are saying, and I appreciate that you as someone who has an excellent grasp of cutting edge technologies have taken a firm position on this issue.  For those of us who are more in the category of workhorses rather than gurus, having a firm guidance in such issues is of tremendous value.  Otherwise one has a tendency to waste a whole lot of time running after the newest without realising that the newest doesn't always mean the best or the most appropriate.  (I suppose for people who are in the job market - they still have to learn the latest to appear current)

Jav

dagware replied on Friday, May 28, 2010

Jav - I agree 100%!

The other thing I wish we could all keep in mind is that the older ways of doing things, in most situations, still work just fine. For example, there's no rule that says we have to use LINQ to SQL or EF. The old code that calls stored procedures and uses SafeDataReader works just fine. For that matter, the pre-CSLA 3.5 ways of using backing fields instead of PropertyInfo works just fine also, if not as elegantly.

We don't *have* to jump on the latest and greatest. Well, maybe we do because we can't help ourselves, but that's a different problem. ;p

Dan

tmg4340 replied on Thursday, May 27, 2010

FWIW, you don't have to "do away" with stored procedures if you want to use EF.  Yes, EF doesn't make it easy to use them (and, from what I've heard, EF 4 doesn't improve the situation much.)  But you certainly can.  I've done it in several instances.  Stored procedures still make better sense over trying to code it in EF (or L2S) in many situations.

This is not meant to say that you should rush out right now and retro-fit everything you have to EF.  If what you have works, then by all means keep using it.  But EF does have its place.  For my own work, I find the abstraction and simplification of much of my database code worth it.  And that's all I use it for - EF entities don't (and won't) make it outside of my DAL, no matter what Microsoft tells me.  Stick out tongue  And since I don't work in a "high performance" environment, any sort of performance loss I might have over SP (which in most of my cases isn't much) doesn't bother me.  But just like all the other "shiny new objects", it doesn't solve everything.

Do I wish Microsoft would slow down their "innovation path" just a little?  In some ways, yes I do.  I agree 100% that their apparent new strategy - what I call Making Up For The Time Between XP And Vista - certainly puts a lot of pressure on the development community.  I'm sure there are times when Rocky just has to roll his eyes, throw up his hands, and ask what he did in life to deserve having to support in CSLA the 8 kajillion ways Microsoft is coming up with to do the same job.  I've basically resolved myself to learning what's coming, and diving in deeper on something when it actually comes into my job scope.  It's not ideal, but it keeps me from going crazy.  Smile

HTH

- Scott

dec698 replied on Thursday, May 27, 2010

RockfordLhotka

No, that is not true. You can use EF from DataPortal_XYZ methods as well.

There are actually four data access models you can use with CSLA:

  1. DataPortal_XYZ direct to data source
  2. DataPortal_XYZ to abstract DAL
  3. ObjectFactory direct to data source
  4. ObjectFactory to abstract DAL

I walk through all four of these in the Core 3.8 video series.

Is there a sample code implementation on this? Im looking thru the 4.0.0 download and your 3.8.3 sample code sample and could not find code sample implementation of EF using DataPortal_XYZ.

any help is appreciated.

(Rocky, aren't you going to run any promotional discounts on your video series any time soon? )

Copyright (c) Marimer LLC