Related
So what's the verdict on these two products now? I can't seem to find anything regarding this issue SPECIFICALLY for VS2010/.net 4.0
Back in .net 3.5 days, most people believe Linq2SQL will be dead when .net 4.0 comes around, but it seems alive and well.
On the other hand, EF 4.0 seems to have gotten significant improvement.
For me, most of my work so far are small to medium sized projects, and my company is migrating from VS08 to VS10 soonish. What should I be looking at? Or really, should I spend the time studying EF4.0 or would it be time more well spent looking at nHibernate? (But back on topic, I'm really more interested in Linq2Sql - EF.)
Lastly, I am currently using entlib / unity, which framework is more friendly for dependency/policy injection?
Thanks in advance.
Here are some reasons why Entity Framework (v4) is better:
1 - L2SQL is essentially obsolete
2 - L2SQL does not support POCO mapping, EF does.
3 - EF has more flexibility (code first, model first, database first). L2SQL has only 1.
4 - EF has support for SPROC -> POCO mapping
5 - EF has Entity-SQL, allowing you to go back to classic ADO.NET when required
6 - EF supports inheritance (TPT, TPH)
7 - EF goes hand-in-hand with Repository pattern, and deferred execution via IQueryable
8 - EF components (ObjectSet, ObjectContext) are easily mockable and allow for DI
I cannot think of any reason why new projects should use L2SQL.
Some might say "Well L2SQL is good for small projects, i can drag and drop and be done with it".
Well you can do that with EF4 as well, and you'll have more flexibility/support in the long run if you decide to modify/grow your project. So that is not an excuse.
HTH
Just to add to the previous answers and comments (all three got a +1 vote from me):
a) Performance: the L2S runtime is more lightweight than EF (due to only a single layer; EF has to deal with two model layers and the mappings between them).
EF often generates a bit more verbose TSQL than L2S but most of the time that only affects readability if you're profiling and looking at the generated queries; the SQL optimizer will end up with the same execution plan most of the time. There are however some cases when the queries can grow so large and complex that it can have a performance impact.
L2S is also slightly better at doing client-side optimization of queries; it eliminates where clause predicates that can be evaluated client-side so the database don't have to worry about them. This means less work for SQL Server's optimizer, and less risk that you'll end up with a 'bad' execution plan.
b) L2S vs L2E: L2S is still slightly better than L2E at translating LINQ queries that use normal CLR methods into TSQL, especially when it comes to DateTime and methods related to it. L2E supports more or less the same things but through its' own EntityFunctions class: http://msdn.microsoft.com/en-us/library/system.data.objects.entityfunctions.aspx.
Both L2S and EF are great choices in my opinion, pick the one you feel comfortable with and covers the things you need now and during the reasonable lifespan of the code you're writing. Before you know it, Microsoft will probably announce yet another data access technology. They seem to do that every 3-5 years... :) DAO, RDO, ODBC, ADO, OLEDB, ADO.NET, typed datasets, ObjectSpaces, WinFS, L2S, EF, ... etc etc. Code I wrote 15 years ago against DAO is still out there, in apps that are still on the market, and it still works despite DAO being "dead" for years.
Sometimes names are reused for completely new data access technologies, but that doesn't change the fact that whatever constitutes Microsoft's latest database access technology is a constantly moving target...
L2S isn't going anywhere. The VS team has made that clear. It won't get significant improvement, but it will still be around and work just fine.
L2S is great, and easy to use for small scale projects with fairly simple data models. The trigger for me, when to choose EF over L2S is if I have many-to-many tables, or I need to map more complex entities over more than just a single table.
I know this is probably too late for the original query, but for the sake of future people with a similar question...
To my mind, the crucial aspect is whether you're doing an entirely new project or working with a legacy DB. I'm working with a legacy DB, with some rather idiosyncratic design decisions. I'd like to use EF, but it simply failed to map over these idiosyncracies, while L2S managed perfectly well.
For example. Some of the FKs contained other values than keys to related rows - effectively doubling as an FK/flag column.
Further, the FK inheritance mapping totally failed against out DB, so I opted for a flat L2S model, to get the benefits of type-checking and name checking at query time, but ended building my own mapping layer.
All of this is a horrible pain, if its any consolation to MS, I also found NHibernate incapable of the task. In my experience, in real-world usage too many DBs have these kind of issues, hence my recommendation that EF is not really suitable for brown-field develop ment.
For new projects, you have the luxury of evolving your DB design to match the assumptions of the framework. I can't do that as existing applications rely on the data design. We're hoping to improve the design incrementally, but attempting to correct all the problems up front would result in an infeasibly large migration event (for our resources).
Note: In the UK (at least), brown-field development is building houses on land that has previously been developed. Green-field development is building on our dwindling resources of countryside. I've reused the terms here.
We've just moved from VS 2008 to VS 2010 and from L2S to EF.
Even though we are using EF in a very similar fashion to L2S, it comforts me knowing that I have flexibility to do more advanced ORM should the need arise.
That said - for a small project - I would probably still use L2S. Medium to large projects I would use EF.
Also - EF seemed like a big learning curve, because the EF documentation prompted us to start investigating some design patterns like Unit Of Work, Repository, Dependency Injection. However I realised that these patterns applied to L2S as well as EF.
In terms of Nhibernate - my research (ie. browsing SO) indicates that the latest version of EF4.0 is sufficiently advanced (POCO support etc.) to be considered a competitive product.
If third-party products are appropriate for you, try using LinqConnect. This product allows you to use Linq to SQL (with some modifications) with different DBMS (Oracle, MySQL, PostgreSQL, etc.).
LinqConnect offers you the following features unavailable in L2S earlier:
Model-First approach
TPT and TPH support
POCO support
Automatic synchronization of model and database without data losses.
As for performance, the latest comparative test on OrmBattle our provider is among leaders.
Also, all EF functions are supported in our DBMS-specific providers as well.
I'm not a database admin or architect, so I have to ask those who do it 24/7. How established is the concept of an ORM (object relational mapping) in the world of database administration and architecture? Is it still happening, widely approved but still in its early stages, or is generally disapproved? I'm learning this area and would like to get a feel for whether it's going to be knowledge appreciated by the wider segment of this field.
A lot of places are using them, that doesn't mean they are using them well or that they are a good idea for the long term health of the database. Doesn't mean they aren't either, usually it just means the people choosing them don't think about how this affects database design, maintenance and performance over time.
ORMs are widely used. Django (python web application framework) uses SQLAlchemy. Hibernate is popular for Java programs. ORMs make SQL application development faster, reduce the amount of boilerplate code that you must write, and hide which database you are using from the rest of the application. Performance may suffer using an ORM, so be prepared to customize things as needed.
Widely used and definitely the present and near future. Database access through a handcoded layer of SQL generation was always fraught with drudgery and typos, and was unwieldy at best. ORMs let you use a persistence store in a programming way.
I thought this blog argued for it well: http://jonkruger.com/blog/category/fluent-nhibernate/ and SO posts like this (nHibernate versus LLBLGen Pro) show just how many people are using them.
I can tell you from my experience. We are a $2.5B solar manufacturing company and we are basing our next generation of products on ORM technology. We're using Linq-To-SQL, quite successfully. We are very happy with it.
The concept has been around for at least 20 years.
If you take a look at any decent web framework, whether it's Java, Ruby, PHP, C# or Python, they all incorporate ORMs. Generally, it's perceived as being a more professional choice unless you have specific needs for high performance or custom SQL.
Is Entity Framework worth moving to for a new small app? About 10 tables and a WinForms app.
ie the alternative being DataTables/DataRows or Linq-to-SQL
I'm going to disagree with those who say that LINQ to SQL is preferable for a small project, based on real-world experience using both LINQ to SQL and the Entity Framework for small projects. I have a really hard time getting over LINQ to SQL's incredibly weak schema update scenario (throw away your old model, re-generate a new one, and re-apply your customizations). You can do what you need to do with both tools, for the most part, but if your DB schema will ever change or evolve you'll spend way too much time fiddling with the L2S designer.
The best reason to avoid the Entity Framework is if you don't understand it. I'm not being flip here; if you do understand L2S and you don't understand the EF, then by all means use L2S; you will probably be more productive. But if you understand both tools, the EF can do nearly everything that L2S can do and much, much more (easy model updates, model-first, code-first models, customizable codegen, RIA services, etc., etc...).
Entity Framework is a great product - but it's clearly designed for more advanced, more complex cases, where you need to be able to have a domain object model that is or can be different from your underlying storage model. If you need that - great - but for most smaller apps, this is total overkill and only adds additional layers of performance killers.
For a small app, go with Linq-to-SQL - or have a look at Subsonic. Those both offer quite thin and very simple layers on top of your tables, and they work great for smaller apps.
DataTables are so 1990's .... stay away, they're messy, they're hard to use, they're not pleasant and not efficient to work with.
I would probably go for LINQ to SQL for a small project.
Stay away from datatables. LINQ to SQL should be enough, IMO.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Many developers will claim that moving from one programming language to another is relatively simple especially if the languages are based on similar paradigms. However, in practice the effort comes not from learning the syntax of the language but in developing a deep understanding of the language nuances and more importantly knowing what is offered in the language’s libraries. For example, switching from Java to .Net is not difficult from a syntactic perspective but programming efficiency requires a good knowledge of the available libraries. Switching from PHP to .Net could present an even greater hurdle given the language disparities.
What are the real overheads for a developer to move to a different language in the same paradigm? What if the paradigms are different?
The biggest challenge (for me) is usually the API, rather than the language itself (.NET notwithstanding). For example, I've been using Microsoft's C++ and C# for a lot of years (Delphi before that). But I have great difficulty getting started on Java; even trivial projects can take me a while. Not because the language is difficult (it's not), but because the APIs are different, and arranged differently.
It takes months to get up to speed on an API to the point you can use it fluently, and years to become "good" and learn all the ins and outs of the language. That's daunting for a lot of developers, because you basically have to devote a significant amount (if not all) of your time and effort toward working in the new language to become an expert at it. Many times, the incentive to move out of your current area of expertise just isn't there.
Same paradigm is much easier because it is really just a matter of grasping the various libraries and locating them quickly as you mentioned.
If the paradigms are different than this switch is more difficult. Moving from a static to dynamic language or a procedural to OOP language will require a different mind set. This will take more time but it is possible and still a very good exercise.
It may be similar to learning foreign languages. If you speak English, than moving to another Latin based language is far easier than going to something like Greek.
For me it would finding good bloggers and useful sites on the language. After a while you get to know where the best people are. Those people and sites are good sources of information for learning the subtleties.
leaving your comfort zone. I think this is one of the biggest reasons some developers don't learn new languages.
But for others, this is what drives them.
Moving within the same paradigm is relatively easy. I find that switching between Java and .NET painless because both platforms offer similar functionality and similar libraries. But switching paradigms could be a real challenge.
My students usually have a hard time going to Functional and Logical languages after learning Java even though the functional and logic programming are easier.
Another problem is switching between types of applications. For example, if you are accustomed to building desktop applications in Java then suddenly try to build web applications in .NET the switch is hard because you are not only learning new languages but new fields of programming.
Another challenge is the tool sets that are available for a particular language. Java and .NET have similar tools but with some differences. If you learned to program using Visual Studio then it is possible that features of Visual Studio become confused with the language. I see students having this problem all the time. When you switch to Java and there is no equivalent menu option of wizard in the new IDE it could cause problems.
I advocate to persons learning programming to learn the core concepts of the paradigm rather than the specific language because it makes you more portable in the future. A person comfortable with Object Oriented Concepts will have an easier time switching between Java and .NET or Python than a person who simple learned how to program in C#.
Just like learning a new human language, for me the biggest problem lies on typical constructions you need to do to solve a problem.
I know that perhaps learning "while" or "for" loops in several languages aren't so difficult - but when your problem goes up one level of abstraction (iterate through this array) you'll find yourself using "[" instead of "(" and vice-versa.
The learning curve can be even steeper if, besides learning a new language, you have to learn a new framework. When I went from typícal ASP.Net to MVC (using NVelocity) I kinda felt myself completely lost - all my knowledge on how to solve typical problems with asp.net control had to be forgotten.
Finally, the biggest challenge happens when you change between languages with different paradigms - because you can no longer think in the same way to solve a problem. Like - when moving from C# to Prolog, instead of thinking in functions, arguments, class hierarchy, etcs... I had to think only in states, events linked to data changes and event chaining via recursion - it was madness but I could finish my university homework.
Coming from 15+ years of C++ background I just had to move to Java for a new project I am working on, and this is a rather painful step. There are tools and frameworks for almost everything, but the learning curve is enormous! The new syntax is nothing to worry about, the API is more difficult, but the most difficult area is to find the way through the all the frameworks.
Also, having to use Eclipse as IDE is a step back in terms of stability and reliability compared to Emacs. The features of Eclipse are really compelling, but the bugs in the IDE cause constant hassle.
Just when I make friends with LINQ to SQL, it appears as though MS is pulling the rug out from under it.
http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
From my little bit of research, EF is way overkill for simple work. But after this announcement is there a point in continuing to use LINQ to SQL?
Beyond the future for LINQ to SQL, doesn't this just generally send a bad signal? Given the speed with which MS is throwing bits against the wall, is it rational to use any of the new bits early? (and that's being kind, it's hardly early for LINQ to SQL!).
For my LINQ to SQL work, I think I'm headed to SubSonic!
Update: A couple of new opinions:
http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx
http://codebetter.com/blogs/david.hayden/archive/2008/10/31/linq-to-sql-is-dead-read-between-the-lines.aspx
1) They can't "kill" Linq-to-SQL as it is already part of the .net framework. What they can do is stop adding features to it. That doesn't prevent the thousands of developers out there that are already using L2S from extending it and improving it. Some core areas are tricky to touch but they're solid already and the missing designer features can easily be bolted on.
2) One of the PDC EF sessions show that they have learnt a couple of lessons from the EFv1 fiasco and they are now copy-and-pasting a lot of the goodies from L2S into EF and pretending it is new EF stuff. In other words, L2S version two has just been "relabelled" EF.
3) LINQ as such (Language Integrated Query) is the best thing since sliced ice-cream and it can be used with a lot of other things than L2S (Linq to objects, Linq to entities, Linq to XML, Linq-to-anything). So the DP group's attempt to force [the vast masses of] L2S adopters over to [the less popular and currently flawed] Entity Framework is no reason to not learn Linq.
Also see this thread (which is what I believe partly triggered Tim's blog post):
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4061922&SiteID=1
Update 1: The Dec 2008 issue of Visual Studio Magazine cover story by Roger Jennings is a good read on the topic, with some L2S vs EF comparisons: http://visualstudiomagazine.com/features/article.aspx?editorialsid=2583
Update 2: Anders Hejlsberg was quoted in Redmond Developer News as saying "LINQ to SQL is not dead. I can assure you, it is not dead. Nothing ever goes away. We have never done that and we never will."
http://reddevnews.com/blogs/weblog.aspx?blog=3016
There's an ambiguity to your question that needs to be resolved.
LINQ != LINQ to SQL
There are a whole bunch of LINQ technologies and providers:
Linq to SQL;
Linq to Entities;
Linq to Objects;
Linq to XML;
... and those are just the ones from Microsoft. There are non-MS providers too, including NHibernate.
The blog post you linked talks only about Linq to SQL.
The key advantage to LINQ is that you can learn and use one query syntax and reuse it across multiple technologies.
Given this, I'd suggest that any perceived lack of a future for "Linq To SQL" is irrelevant, as skills you gain in writing LINQ Queries will be transferrable to other tools in the future.
We are not killing LINQ to SQL. We are optimizing for EF, but LINQ to SQL is definitely not being killed off :)
-
Scott / Microsoft.
Not only should you learn Linq (System.Linq.Enumerable and System.Linq.Queryable), you will need to learn the programming language enhancements for your .net language.
In C# 3.0 these include:
Extension methods (static methods with the this keyword on first parameter)
Compiler inferred types (var)
Lambda syntax (which generates an anonymous method or a Expression depending on context)
Initializers
Property default implementation (a shorthand)
Read more here.
In VB 9.0 there's some inline XML magic, and many other things (many are similar to the above list for C#).
Read more here.
I honestly do not understand where in that article you read that link2sql is dead.
In the blog post you linked to it says:
We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.
For me this reads like LINQ to SQL will be developed and supported in future. I wonder why you think it is dead?
Granted, I think that the choice between LINQ to SQL, LINQ to Entities and LINQ to [insert 3rd Party ORM] here provides a perfectly healthy eco-system of data access layer methodologies that a software developer can choose from. Third party providers like NHibernate, LLBLGen and even Subsonic (not sure if they're going to offer LINQ providers) will definitely make the competition better and more interesting.
That being said, it will be totally sad for Microsoft to abandon LINQ to SQL, especially since it does have a good following -- even StackOverflow is built on it.
Interesting blog post about it. And some related information on Stackoverflow posts.
The basic gist appears to be comments made on the ado.net blog that state the Entity Framework is the only thing getting major developer time for Visual Studio 2010 and Dot Net 4.
My response is - DUH. We have all known this. Microsoft said publicly back at the PDC 2007 that LINQ to SQL was a short term release for SQL Server because there was no other LINQ story to SQL Server. It only works with SQL Server. You cannot write a LINQ to SQL provider - there is no model for it. It was a one off technology, not extensible.
The Entity Framework is the ONLY way from Microsoft to build a LINQ Provider. The Entity Framework has turned out to be quite contreversial, but I think that is partly due to the fact that LINQ to SQL has a better programmer experience today. Entity Framework will catch and surpass LINQ to SQL because it is the ORM/Mapping tool of the future from Microsoft.
EDIT - I just did a slightly more detailed write up about this on my blog
EDIT2 - IQueryable Provider - is NOT the same thing as a LINQ to SQL provider. You can write your own IQueryable Provider for anything you like. You get no designer support or model generation. There is no gui designer model that I know of for tying into LINQ to SQL model generation.
I guess I don't really see the problem here. From the article you've linked:
We are listening to customers
regarding LINQ to SQL and will
continue to evolve the product based
on feedback we receive from the
community as well.
Am I missing something? What gives the impression of LINQ to SQL being dead on arrival?
Scott Guthrie told me they would not kill LINQ to SQL:
Post at LINQDev.com
Anyone remember VB6? Whether you personally loathe it or love it, Microsoft sold millions of copies, and businesses spent millions of dollars writing millions of lines of VB6. What happened next?
Well, Microsoft do still support VB6 (kind of - not the IDE).
And Microsoft still say that they are listening to VB6 customers even now (in September 09).
But are VB6 customers happy? Not since 2002, 4 years after VB6 launched.
Why not? The upgrade paths for your code investment to the replacement technology, VB.Net, are expensive.
So just consider that lesson. To me, it seems LinqToSQL support will be rather grudging. They are obliged to support it because it is in the current .NET framework. But will it be in .NET 5, 6, 7...? Just think about how much that matters to you (for all I know, it doesn't matter to you at all).
Maybe you should not bother learning Linq to SQL, but there's still the Entities Linq that they will keep.
See also http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx and the the comments there
Its obvious that 2 ORMs is one to many in Microsoft's toolbox, but to me it seems to be the wrong framework has been chosen for all the wrong reasons. The fact that the C# team did the job that the ADO.NET team was supposed to do in lot shorter time and did the job way better is tough to swallow for the ado.net team. Not that I know the internal workings of the 2 frameworks but I think it would be a lot faster to upgrade the shortcomings linq2sql has to the entity framework.
There seem to be too much politics involved and I think this is really going to hurt the asp.net reputation, since I have no trust in that Entity framework will give us a equally user friendly experience as Linq2sql. The ado.net team could also learn some communication skills from the asp.net mvc team as the clarifications on the problem is at best vague.
It would be fun learning what Scott Gu and his MVC team stands here as most of their examples are using Linq2Sql.
It was always a bit weird that with Linq 2 Sql and Entity Framework there was large areas of overlap. I think the only reason L2S only ever made it into the .NET 3.5 release was because there was a large doubt that EF would ever see the light of day. Now that EF1 is out, all be it a very rough v1, there was no need for L2S anymore.
(no, StingyJack, LINQ to SQL does not use the entity framework)
Anyway, I wouldn't worry. Tim states that they are listening to customers regarding LINQ to SQL. Judging from the enthusiasm I've seen for L2S, the customers (that's us) will speak their minds.
And, as KristoferA points out, they can't actually 'kill' L2S, only freeze it. And L2S, once polished, doesn't really require much further development. With the L2S provider in place, any advances in LINQ should be available in L2S as well. So the choice will still be ours.
The next version of Windows Phone 7, codename Mango, includes a SQL Server Compact Edition accessible via Linq to SQL http://jesseliberty.com/2011/05/10/coming-in-mangosql-server-ce/