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.
The relative simplicity of Linq-To-Sql as well as all the criticism leveled at version 1 of Entity Framework (especially, the vote of no confidence) convinced me to go with Linq-To-Sql "for the time being". Now that EF 4.0 is out, I wonder if it's time to start migrating over to it.
Questions:
What are the pros and cons of EF 4.0 relative to Linq-To-Sql?
Is EF 4.0 finally ready for prime time?
Is now the time to switch over?
Well, an endless debate :-)
Yes, I firmly believe EF4 is definitely ready for prime time - Microsoft has done an outstanding job of addressing just about all the annoyances and issues with the 1.0 release of EF.
It's ready for prime time - if you need all its features.
Linq-to-SQL is a pretty straightforward, no-frills, no-nonsense OR mapper - it maps one database table to one CLR object - and that's about it. Very basic, very direct - but a rather thin layer on top of SQL Server.
EF4 on the other hand is much more
a conceptual data model in your object space
a storage data model on your database layer
a mapping layer between the two
database-independent
So if you really need support for multiple databases (and not just SQL Server), or if you really need to be able to morph the database structure into a totally different object model - EF4 is a great place to start.
If you have a simple and straightforward little to medium-size app that only needs to be able to easily and quickly map tables 1:1 to objects, then I don't think EF4 comes even close in terms of simplicity and performance to Linq-to-SQL.
EF4 is great - and if you need its power - go with it!
But if your requirements are a lot less, it might just be overkill - continue to use Linq-to-SQL (I will) and be happy with it. I don't see any good reason to dump Linq-to-SQL - it's still totally available in .NET 4, has been blessed with some bug fixes and improvements even, and it will be around for at least another couple of years.
#marc_s, #DanM:
Please do not consider this post as an advertisement :) We just want to know the opinion of advanced users of Linq to Sql.
We have implemented the following improvements in our LinqConnect (Linq to Sql Server, Oracle, MySql, PostgreSql, SQLite):
- Complex Type
- Many to Many
- Batch update operations
- Recursive support in DataLoad options
- Query level preload (like Include in EF)
- TPT support (in LinqConnect 2.0)
We also plan to add support for second level cache.
Are these improvements valuable for you?
I've got an app that is just over 1yr old but it still evolving and will likely revolve more and more around a growing database schema in the near to mid term. The app was written using LinqToSql which has met our needs fairly well. We have run into a few pain points but have worked around them. I would currently consider this app to have fairly minimal database demands.
Now that the EntityFramework appears to be the ORM Microsoft is pushing people towards I'm wondering if it isn't inevitable that we will want to migrate in that direction.
I have heard a lot of good and bad about EntityFramework. So I am wondering if I would be better of taking the plunge now or waiting for v2.0 when VS10 arrives? Any thoughts? Will I lose any functionality if I do it now?
If I were to decide to migrate, can anyone point me at some resources on what is involved?
Thanks!
Re wait or change now? Personally, I'd wait (see Do you think it’s advantageous to switch to Entity Framework?) for VS2010 (as a minimum) - and until the beta comes out I can't check whether the things I use in L2S that EF lacks are implemented yet.
The resources etc question may be a dup of How to move from Linq 2 SQL to Linq 2 Entities??
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/