|
And the winner is… LINQ to Entities and the ADO.NET Entity Framework[^]
In 2001 we first demonstrated Object Relational Mapping (ORM) technology for .NET – ObjectSpaces. However it has taken 6+ years to get to the point where we have released an ORM. Actually we released two.
* The release of Visual Studio 2008 in November 2007 gave us our first shipping ORM – LINQ to SQL.
* The release of Visual Studio 2008 SP1 in August 2008 gave us our second shipping ORM – LINQ to Entities or more specifically, the ADO.NET Entity Framework.
Which reminds me of waiting for a bus. You wait and wait and wait and then finally two come at once! Anyway – I digress.
Choice can be a great thing but it was pretty obvious that having two ORM technologies from one supplier was causing a lot of confusion amongst Windows developers keen to benefit from using an ORM on their projects. I have previously discussed how to choose between these two technologies but things have got much clearer over the last few days.
Last week Tim (Program Manager on the team) posted an update on the roadmap. My summary in one line would be:
* The Entity Framework (v2) will be the recommended way of using an ORM in Visual Studio 2010 and .NET 4.0. LINQ to SQL will not.
|
|
|
|
|
Kevin McFarlane wrote: * The Entity Framework (v2) will be the recommended way of using an ORM in Visual Studio 2010 and .NET 4.0. LINQ to SQL will not.
Especially, as per an article linked to in one of the recent CP newsletters, Linq2Sql was never supposed to be released to the public and looks like it'll be unsupported in the future.
Marc
|
|
|
|
|
Marc Clifton wrote: was never supposed to be released to the public and looks like it'll be unsupported in the future
Sounds like Paris Hilton...
|
|
|
|
|
Remember that all excitement Microsoft tried to raise for Linq to Sql and now it is going to disappear. Would ADO.NET Entity Framework have a better future?
TOMZ_KV
|
|
|
|
|
Well, if it goes belly up there are loads of alternative ORMs out there for people to use.
Kevin
|
|
|
|
|
What the heck are these idiots talking about? I detest the use of well-defined technical terms by morons to describe concepts that are totally unrelated. It's on a par with psychics using terms such as "magnetic field" and "electric force" to describe psychic phenomena which, if they relied upon either, would have been easily measured long ago. The immediate impreesion this causes is one of complete ignorance of any scientific knowledge, and incompetence beyond description.
Having waded through the article referenced, though, it seems like a nice idea - to reduce the complexity of accessing traditional relational database information using ADO.Net. That's a good thing. But I'm not sure introducting yet another level of abstraction to the model will be readily accepted by those who have been using existing methods for years. Maybe a new generation of programmers will find it useful, having learned it from the beginning of their careers, but those who have already mastered the skills required will not likely change their ways. If it ain't broke, why fix it?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Roger Wright wrote: It's on a par with psychics using terms such as "magnetic field" and "electric force" to describe psychic phenomena
I was browsing this new age magazine while waiting to check out at the grocery store. The typical article goes like this: mention Feynman or Einstein, mention quantum physics, use authorities and science to then say, see? we have scientific proof that our ideas are correct. This one, in particular, was talking about using tuning forks on your chakras because, according to Feynman, quantum physics, and string theory, everything has a vibrational frequency. Sigh. It's one thing to just say, hey, we're trying out this funky tuning fork therapy on people. But please, don't try to bolster your ideas with logic fallacies.
[edit]And yeah, I hate it when people use that term "impedance mismatch" to describe the disconnect between the DB schema and the code representation.[/edit]
Marc
|
|
|
|
|
Marc Clifton wrote: And yeah, I hate it when people use that term "impedance mismatch" to describe the disconnect between the DB schema and the code representation
Do you have a better term? 'Disconnection between the DB schema and the code representation' seems a bit too long to me...
I don't stick to terms. Maybe because the English language is not my native one, I haven't found anything bad yet on the term 'impedance mismatch' - but this may well be because I don't get all details of it.
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Thomas Weller wrote: Do you have a better term?
Well, "schema mismatch" or "representation mismatch" come to mind.
The hardware definition is:
mpedance matching is the electronics design practice of setting the output impedance (ZS) of a signal source equal to the input impedance (ZL) of the load to which it is ultimately connected, usually in order to maximize the power transfer and minimize reflections from the load.
Which really doesn't match, even abstractly, IMO, with what is going on between the DB schema and code.
[edit] I guess I'm experiencing an impedance mismatch in terminology, harhar [/edit]
Marc
|
|
|
|
|
Thanks for this clarification. I really didn't know that.
Marc Clifton wrote: Which really doesn't match, even abstractly, IMO, with what is going on between the DB schema and code.
I fully agree. This definition seems to totally miss the point...
Regards
Thomas
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
Marc Clifton wrote: using tuning forks on your chakras
Now there's a unique idea. 
A musician named Stephen Halpern was using music (basic scales) to 'tune' chakras about 25 years ago. While I have to admit that the therapy had a noticable effect, he didn't resort to quoting science terms to explain it.
Anyone who uses impedance in reference to software should look up the meaning of impedance. For me, the improper usage just impedes my acceptance of the article. 
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Thank you. I spent the afternoon playing "planning poker" with two co-workers. The site is actually a decent gimmick for keeping a discussion on track, but doesn't really resemble any version of poker that i've ever played.
And then there are "scrums" (that don't involve full-contact sporting activities), "burn down charts" that don't involve actually burning anything, "user stories" with no narrative, and all manner of "belts" awarded to people based on their skill with statistics.
Too many programmers wishing they were doing something else...
---- You're right.
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets .
|
|
|
|
|
I can't connect to DB2 database with EF. I think it has only MS SQL Server support like LinqtoSQL.
Some says that you can but there is no way to select other data sources like DB2 or Oracle.
|
|
|
|
|
The new drivers from Devart (formerly Core Labs) supports accessing Oracle, MySQL and PostgreSQL from the Entity Framework. There are also shipping Entity-Framework capable drivers available for SQLLite, Sybase SQL Anywhere, and a PostgreSQL driver from Npgsql.
IBM has been involved since the beginning and has demonstrated support for DB2 and Informix. Data Direct has been involved as well, and Microsoft has been working with Oracle on updating their provider to support the Entity Framework. Oracle joined Microsoft in a discussion on supporting the Entity Framework at Tech Ed, but has not made any announcements as to availablity of Entity Framework support in their provider.
We expect other vendors to upgrade their providers to support the Entity Framework in the coming months. For a list of vendors the had already committed to support for the Entity Framework as of December of last year, see http://blogs.gotdotnet.com/adonet/archive/2007/12/17/the-ado-net-entity-framework-not-just-for-sql-server.aspx.
HTH,
-Mike
|
|
|
|
|
Apparently, lots of people, seeing the amount of effort that goes in to hiding it!
SQL is not the best ever designed language but, common, it's not that bad!
Regards.
|
|
|
|
|
PedroMC wrote: SQL is not the best ever designed language but, common, it's not that bad
It is very good for interactively querying data and making changes (e.g. for DBAs and business analysts)
As a mean of handling data from applications it is horrible: typeless and prone to security flaws. Most application programmers construct SQL queries on the fly:
query = "SELECT * FROM Sometable WHERE SomeField=" + myEditControl.Text
This is pure evil
|
|
|
|
|
Nemanja Trifunovic wrote: As a mean of handling data from applications it is horrible: typeless and prone to security flaws. Most application programmers construct SQL queries on the fly:
Because most don't know SQL well.
Nemanja Trifunovic wrote: query = "SELECT * FROM Sometable WHERE SomeField=" + myEditControl.Text
In all sincerity if you think that's horrible, then in pseudocode what would you do that's so superior to go about telling a DB you want to pull values from a storage mechanism where the condition for which rested in myEditControl.Text?
I'm not saying you, but in my experience the people that knock SQL the most are the ones that know it the least. It offers a lot of nice short cuts in it as well that can shorten the amount of time you would have to query compared to writing code. Sure it has its ups and downs, but so does anything (expect me of course  ).
|
|
|
|
|
Jeremy Falcon wrote: In all sincerity if you think that's horrible, then in pseudocode what would you do that's so superior to go about telling a DB you want to pull values from a storage mechanism where the condition for which rested in myEditControl.Text?
Something like:
result = DataStorage.GetSomething(myEditControl.Text)
But even with SQL, there are parameterized SQL queries (even in MySQL these days, since version 5.0 or something  ) which would at least prevent SQL injections.
|
|
|
|
|
Nemanja Trifunovic wrote: result = DataStorage.GetSomething(myEditControl.Text)
But you can do that with a wrapper already if you prefer objects over a query string.
Remember, SQL specifies syntax that's meant to be standardized, much like how XML, HTML, etc. does, so you don't get everyone and their mother specifying their own thing underneath the hood. It's not supposed to interact with objects in your app intrinsically as it was never created for that means, and you would throw portability out the window that way as then data access would be solely dependent on the environment accessing the data rather than database.
|
|
|
|
|
Jeremy Falcon wrote: But you can do that with a wrapper already if you prefer objects over a query string.
If my wrapper internally does the same thing (appends a user-supplied string to a query) then there is no point.
SQL is inherently bad, for the similar reasons printf(...) is bad: it requires an interpreter that blindly executes strings that often contain parts supplied by users. I attended a couple of security seminars lately, and examples of exploiting this fact were abundant.
|
|
|
|
|
The same argument could be said about a programming language. Especially the ones that allow you to dynamically execute code.
What I'm getting at is SQL does more good than harm by providing an open means rather than closing it off. Abusing it is bad, then again so is anything.
|
|
|
|
|
Nemanja Trifunovic wrote: As a mean of handling data from applications it is horrible: typeless and prone to security flaws. Most application programmers construct SQL queries on the fly:
Btw, SQL isn't typeless. It's loosely typed, but that's not the fault of SQL, that's the fault of MS and SQL Server as that's one of the most forgiving RDBMSes out there. Some like that, some don't. But even still, it's not hard to enforcing typing in the application before it's sent to the DB.
|
|
|
|
|
Jeremy Falcon wrote: that's the fault of MS and SQL Server as that's one of the most forgiving RDBMSes out there.
|
|
|
|
|
What I'm trying to say is SQL Server is so forgiving it starts to loose the value of its intrinsic data types because you can mix and match so easily in it whereas you can't in other RDBMSes.
|
|
|
|
|
Jeremy Falcon wrote: What I'm trying to say is SQL Server is so forgiving it starts to loose the value of its intrinsic data types because you can mix and match so easily in it whereas you can't in other RDBMSes.
I was not talking about that, but would like to see some evidence anyway 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
