LINQ to SQL vs ADO.NET EF
-
Which is your preferred choice when developing DAL with LINQ? LINQ to SQL or ADO.NET EF. I can’t see much of a difference so I’m a little bit in dilemma what to use. Which is better? What are the main differences? I’m currently using MS SQL Server but would like to be able to support Oracle if needed. Suggestions? Thx
Vlatko
-
Which is your preferred choice when developing DAL with LINQ? LINQ to SQL or ADO.NET EF. I can’t see much of a difference so I’m a little bit in dilemma what to use. Which is better? What are the main differences? I’m currently using MS SQL Server but would like to be able to support Oracle if needed. Suggestions? Thx
Vlatko
Possibly the biggest differences are: 1. The EF allows you to create an object that spans multiple tables. 2. The EF doesn't use LINQ at it's core.
Vlatko wrote:
I’m currently using MS SQL Server but would like to be able to support Oracle if needed. Suggestions?
Take a look at NHibernate/ActiveRecord instead.
Deja View - the feeling that you've seen this post before.
-
Possibly the biggest differences are: 1. The EF allows you to create an object that spans multiple tables. 2. The EF doesn't use LINQ at it's core.
Vlatko wrote:
I’m currently using MS SQL Server but would like to be able to support Oracle if needed. Suggestions?
Take a look at NHibernate/ActiveRecord instead.
Deja View - the feeling that you've seen this post before.
Care to explain what you mean with "use LINQ at it's core" ? Linq is used to describe queries; either by filtering ienumerables through delegates OR by an linq expression tree that is transformed into something else, eg SQL. Any framework/tool that can transform a linq query into SQL or any other sort of output do use linq expression trees.
-
Care to explain what you mean with "use LINQ at it's core" ? Linq is used to describe queries; either by filtering ienumerables through delegates OR by an linq expression tree that is transformed into something else, eg SQL. Any framework/tool that can transform a linq query into SQL or any other sort of output do use linq expression trees.
Roger Alsing wrote:
Care to explain what you mean with "use LINQ at it's core" ?
Yup. At it's heart, EF is fairly DML agnostic. While it CAN use LINQ, it isn't designed to rely on it. That's why I was fairly specific in my use of wording, rather than saying it doesn't use LINQ.
Deja View - the feeling that you've seen this post before.
-
Roger Alsing wrote:
Care to explain what you mean with "use LINQ at it's core" ?
Yup. At it's heart, EF is fairly DML agnostic. While it CAN use LINQ, it isn't designed to rely on it. That's why I was fairly specific in my use of wording, rather than saying it doesn't use LINQ.
Deja View - the feeling that you've seen this post before.
Ok, I guess I just see things a little different in this matter. IMO, the by far largest part of an O/R Mapper is not the query support, that is secondary. The big parts are identity management, unit of work, and alot of infrastructure stuff like lazy load, dirty tracking etc. Query support is only a small small part of what an ORM does. and Linq is only related to the query part. But I guess you are reffering to what intermediate sturcture queries use internally in the mapper. Eg, NHibernate will use its criteria API internally, NPersist uses its NPath DOM, and EF might have its own query DOM of some sort. While Linq to SQL will use the Linq Expression tree directly, and never translate it to any special structure. Right?
-
Ok, I guess I just see things a little different in this matter. IMO, the by far largest part of an O/R Mapper is not the query support, that is secondary. The big parts are identity management, unit of work, and alot of infrastructure stuff like lazy load, dirty tracking etc. Query support is only a small small part of what an ORM does. and Linq is only related to the query part. But I guess you are reffering to what intermediate sturcture queries use internally in the mapper. Eg, NHibernate will use its criteria API internally, NPersist uses its NPath DOM, and EF might have its own query DOM of some sort. While Linq to SQL will use the Linq Expression tree directly, and never translate it to any special structure. Right?
Roger Alsing wrote:
But I guess you are reffering to what intermediate sturcture queries use internally in the mapper. Eg, NHibernate will use its criteria API internally, NPersist uses its NPath DOM, and EF might have its own query DOM of some sort. While Linq to SQL will use the Linq Expression tree directly, and never translate it to any special structure. Right?
Exactly.
Deja View - the feeling that you've seen this post before.
-
Roger Alsing wrote:
But I guess you are reffering to what intermediate sturcture queries use internally in the mapper. Eg, NHibernate will use its criteria API internally, NPersist uses its NPath DOM, and EF might have its own query DOM of some sort. While Linq to SQL will use the Linq Expression tree directly, and never translate it to any special structure. Right?
Exactly.
Deja View - the feeling that you've seen this post before.
Somewhat offtopic. I'd say its better to use an intermediate structure than using the linq expression trees straight off. Because no mapper in the world will ever be able to handle a complete Linq Expression Tree. Eg. how do you translate a delegate invocation into SQL? You probably don't , thus if a mapper encounters a reference to a delegate in the expression tree, it should throw and warn that the query is invalid and not supported. If you are using an intermediate structure, you will find this kind of errors directly when the query is translated. If you translate expression trees directly into SQL , then you won't find the problem untill you try to execute the query. This might seem like a very minor difference, but I do think its much cleaner to reject a query directly when it is passed to the mapper , than to accept the query and then fail to execute it later.. Ok, alot of text about nothing :)
-
Somewhat offtopic. I'd say its better to use an intermediate structure than using the linq expression trees straight off. Because no mapper in the world will ever be able to handle a complete Linq Expression Tree. Eg. how do you translate a delegate invocation into SQL? You probably don't , thus if a mapper encounters a reference to a delegate in the expression tree, it should throw and warn that the query is invalid and not supported. If you are using an intermediate structure, you will find this kind of errors directly when the query is translated. If you translate expression trees directly into SQL , then you won't find the problem untill you try to execute the query. This might seem like a very minor difference, but I do think its much cleaner to reject a query directly when it is passed to the mapper , than to accept the query and then fail to execute it later.. Ok, alot of text about nothing :)
Actually I agree. While the premise of deferred execution is, on the surface, neat - underneath it's potentially very, very fraught. I used Xpress Persistent Objects, NHibernate and ActiveRecord - and I just prefer them to LINQ. There are parts of it where I find LINQ really neat, but there are so many trade offs and blurring of boundaries that I go back to the "old" ORMs now.
Deja View - the feeling that you've seen this post before.
-
Actually I agree. While the premise of deferred execution is, on the surface, neat - underneath it's potentially very, very fraught. I used Xpress Persistent Objects, NHibernate and ActiveRecord - and I just prefer them to LINQ. There are parts of it where I find LINQ really neat, but there are so many trade offs and blurring of boundaries that I go back to the "old" ORMs now.
Deja View - the feeling that you've seen this post before.
Yeah LINQ to NHibernate has been in development for a while now, and TBH I haven't even had the inclination to check on it. HQL queries have been enough for my needs. I tend to either want one or more domain object, or an aggregation, I rarely want an anonymous type containing some unstructured garbage. The few people that have asked about LINQ for Diamond Binding seem to be happy using HQL as well. LINQ would worry me for a team involving juniors. Theres certainly some subtlety which would end up biting you (untranslatable queries, deferred execution, etc).
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games.