9

To be clear, I am not asking for a side by side comparision which has already been asked Ad Nauseum here on SO. I am also Not asking if Linq2Sql is dead as I don't care. What I am asking is this....

I am building internal apps only for a non-profit organization. I am the only developer on staff. We ALWAYS use SQL Server as our Database backend. I design and build the Databases as well. I have used L2S successfully a couple of times already.

Taking all this into consideration can someone offer me a compelling reason to use EF instead of L2S?

I was at Code Camp this weekend and after an hour long demonstration on EF, all of which I could have done in L2S, I asked this same question. The speakers answer was, "L2S is dead..." Very well then! NOT! (see here)

I understand EF is what MS WANTS us to use in the future(see here) and that it offers many more customization options. What I can't figure out is if any of that should, or does, matter for me in this environment.

One particular issue we have here is that I inherited the Core App which was built on 4 different SQL Data bases. L2S has great difficulty with this but when I asked the aforementioned speaker if EF would help me in this regard he said "No!"

Refracted Paladin
  • 12,096
  • 33
  • 123
  • 233
  • Anyone care to elaborate on the down vote? Should this be a CW or something? I don't mind being down voted I would just prefer to know why so I can do better next time. – Refracted Paladin Apr 14 '10 at 00:17
  • I was wondering about your comment regarding multiple databases. Where does the difficulty lie? Linq to SQL has an overload for the DataContext that allows you to specify the database you want to open, and joins are a problem for multiple databases in any case. – Robert Harvey Apr 16 '10 at 16:37
  • @Robert Harvey: The difficulty lies in this scenario...In a database called CMO there is a table name tblDiagnosisCues. In a database called MCP there is a table named tblPlanDiagnosis. These two tables are linked by FK, DiagnosisCueID. When I want to pull the Diagnosis's for a plan I have to get the descriptions from the CMO database. I had hoped that EF would simplify this by allowing me to create an Entity for Diagnosis that didn't care where the data was coming from. That clearer? By the by, I DID NOT design these DB's! – Refracted Paladin Apr 16 '10 at 18:12
  • Yes, that is clearer. The problem is not so much the ability to model the data in classes as it is the ability to get effective joins from two different databases. In SQL Server, you can link two sql databases together by running the sp_addlinkedserver stored procedure, and then prefacing the tables you want to join in your SQL statement with their respective server names. See http://msdn.microsoft.com/en-us/library/ms190479.aspx for more details. – Robert Harvey Apr 16 '10 at 21:08
  • To perform table joins over multiple databases using Linq to SQL, have a look here: http://stackoverflow.com/questions/352949/linq-across-multiple-databases – Robert Harvey Apr 16 '10 at 21:11

10 Answers10

8

With EF you get a mapping layer (i.e. your entities) between your class objects and your database tables. If you need that kind of flexibility, or prefer a domain-driven design model (as opposed to a table-driven design), EF might be worth considering. Linq to SQL is pretty much a class-to-table mapper.

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • So, to try and clarify for myself, you are saying, as an example, that if I have DB's that I have no control over EF will allow my to make classes that make sense for my app irregardless of the table structure where as L2S will not? – Refracted Paladin Apr 12 '10 at 16:57
  • 1
    @Refracted: For the most part. Obviously EF will not make up for a really bad database design, but it can smooth things over considerably. Also, some people prefer a domain-based design, where the underlying tables can, in fact, differ from the actual domain objects. – Robert Harvey Apr 12 '10 at 17:05
  • @Robert Harvey: So would it be fair to say that since I design all DB's, besides the aforementioned inherited ones, that EF's benifit in this area is minimal? That is unless of course I design a crappy DB and then try to use it. – Refracted Paladin Apr 12 '10 at 17:15
  • 2
    Correct, if your design is table-based, and you are comfortable with direct mapping of tables to objects, you should feel good about continuing to use Linq to SQL. If you ever need EF for mapping work, or to hook up to another database that is not SQL Server, you can always add an EF data context to your solution. – Robert Harvey Apr 12 '10 at 17:18
  • Most people prefer to think in terms of objects, not in terms of tables. – BlueRaja - Danny Pflughoeft Apr 14 '10 at 19:03
  • @BlueRaja: I didn't see that study. I'm an old-school SQL database programmer, so I prefer thinking in terms of tables for data persistence, especially for small applications. But, to each his own. – Robert Harvey Apr 14 '10 at 19:09
  • When you get into bigger applications, having to constantly worry about the database becomes a **major** pain. In a good, correctly setup O/RM (like NHibernate), you should not even have to think about the database while coding - it handles itself. Of course, Entity Framework is nowhere near this level yet. – BlueRaja - Danny Pflughoeft Apr 16 '10 at 15:51
7

I big reason not to use Linq2SQL is that it has a significant implcit design flaw:

The recommended best practice for using a DataContext is that it be used in a short lived "unit of work" style. Great, except that it's a moderately expensive object to keep creating and disposing of in the first place.

The snag comes in when you want to deserialize or recreate an object (perhaps, from a submitted web page) and then update an existing record. The Attach method offered by the Linq-to-sql will only accept the following three scenarios:

  1. You implement timestamps on all your tables.
  2. You re-select the entity you want to change, then change it and submit.
  3. You magically just happen to still have the original version of the object around.

The first scenario requries database changes, which for some environments is unacceptable. The second scenario is down-right inefficient - why retrieve data you already have? The third scenario is un-realistic - stateless web apps don't typically retain historic information.

The point here is... EF4.0 allows you to reattach an object to an ObjectContext and mark it as added or new, and the context will generate the correct INSERT/UPDATE statement accordingly.

Mark
  • 9,320
  • 6
  • 57
  • 70
4

I've often wondered this myself as EF seems to add a lot of complexity over L2S. Since MS is actively developing EF, there are some new aspects of EF 4 that may be worth checking out. There is a nice summary on the ADO.NET team blog that describes how the API for EF is evolving to support a wider range of development patterns.

In particular, I'm personally interested in support for POCO and the repository pattern as they are a nice fit for the projects I work on. In my opinion, one compelling reason to use any particular provider is how easy it will be to switch to a completely different provider in the future (without overhauling all of your application code, of course). I find L2S lacking in this respect (out of the box, anyways), and I'm happy to see the changes in EF 4. So far, however, I have only been reading about these changes in EF 4, so I can't say how well they actually work in practice.

Michael Petito
  • 12,891
  • 4
  • 40
  • 54
3

EF is geared to be an all out ORM where your object model is significantly different then your DB schema. L2S is more aimed at being a quick DAL generator.

The problem is that EF is a mediocre ORM, while L2S is a really great DAL generator.

I would say if L2S fits your needs, stay with it and don't let MS marketing push you around. If L2S doesn't do what you need it to do, and you need to stay in microsoft products, go with EF. If you have a bit of freedom over your technology, look into NHibernate and LLBGen (imo both are better then EF)

Matt Briggs
  • 41,224
  • 16
  • 95
  • 126
2

They are both very buggy. I've found 8 bugs in Entity Framework since I started using it a month ago (two affect L2S, at least three are still present in EF4). It has been one of the most painful experiences of my life.

The separation of classes and tables would be really nice, though, if EF worked the way they wanted it to.

BlueRaja - Danny Pflughoeft
  • 84,206
  • 33
  • 197
  • 283
1

I asked myself this question when I first saw EF and I'd already written a large application in Linq2Sql. The biggest change is done in the object mapping layer. In EF relationships and navigation is managed for you. So if I have two tables that have a foreign key relationship (say Pets and Owners) I can do 

pet.owner

whereas in L2S I'd have to write the join query myself. Many-to-many mappings are handled sweetly in that if you have a 'pure join table' (that is a table with the two foreign keys and no other data) then this table is not represented in the object mappings.

You can also handle eager/lazy loading yourself.

I can also develop in POCOs so I'm not tied to the framework directly i.e. I don't have all the noise of the L2S or the EF types getting in the way, this makes testing way easier.

Overall I much prefer EF but YMMV

Kevin Jones
  • 2,369
  • 16
  • 26
  • Great answer! I am curious though, and I will try and verify this myself, but, as to, your point about `pet.owner` I thought that was also possible in L2S. I could be mistaken and I am going to go look in my code where I thought I was doing that. Your other points, though, seem quite valid and have me thinking. – Refracted Paladin Apr 13 '10 at 12:45
  • pet.owner - possibly - it's a while since I used it - I'd have to go back and check, maybe somebody else can confirm – Kevin Jones Apr 13 '10 at 12:54
  • 3
    @Refracted: If a relationship exists between the two tables in the Linq to Sql designer, you can indeed reach through the `pet` object in this manner, and grab the `owner`. – Robert Harvey Apr 14 '10 at 19:12
  • @Robert Harvey: Thanks, though I am pretty much back to square one, now, on my question..... – Refracted Paladin Apr 14 '10 at 19:40
  • -1 This is misleading. If L2S knows about your table relationships then they are indeed mapped as properties in the same way as EF. – Kirk Broadhurst Jul 19 '10 at 00:14
0

Well, at the end depends on requisites.

Now you uses linqtosql and it is right for you, but maybe one day you have more sophisticated requisites that you can better complish with EF. For instance using velocity or whatever.

Pablo Castilla
  • 2,723
  • 2
  • 28
  • 33
0

Entity Framework has better compatibility if you expect your application to scale on other DBMS, that's one of it's main advantage.

Entity Framework will work on DBMS other than Microsoft SQL Server, like Oracle, MySQL etc.

While Linq is limited to MS SQL Server.

GenEric35
  • 7,083
  • 3
  • 24
  • 25
  • Thanks for the answer but if you'll notice, in my original post..."*We ALWAYS use SQL Server as our Database backend.*" So that is not really a plus for me in this case. – Refracted Paladin Apr 13 '10 at 13:24
0

L2S allows for implicit lazy loading while the EF has explicit lazy loading. In a small project the implicit work done in L2S is certainly nice and good for rapid development & changes to the model but in larger projects, developers may want more control over what database resources the app is calling.

See http://www.singingeels.com/Articles/Entity_Framework_and_Lazy_Loading.aspx

Nick Gotch
  • 9,167
  • 14
  • 70
  • 97
0

I made the switch from Linq2Sql to Entity Framework some time ago for all my projects. Initially it was a step backward in several regards - date expressions that worked just fine in Linq2Sql didn't work in EF and there was no lazy loading option. But now, with Entity Framework 4 everything works smoothly.

If it's just you and you don't have time to learn EF, stick with Linq2Sql. But if you do have time and think you might eventually want other forms of inheritance than -per-table, or any of the other features of EF, go for it!

And the #1 reason you should make the switch: Entity Framework experience will look good on your resume!

Ian Mercer
  • 38,490
  • 8
  • 97
  • 133