Develop Reference

Linq-to-SQL vs Entity Framework in database-first approach

I got confused on what are the differences between Linq-to-SQL and Entity Framework when following the database first approach as I can not find any clear differences.
In my case when I was using Linq-to-SQL I used to create the tables then I use Linq-to-SQL to create the classes that represents the tables, and now when I switch to Entity Framework I am still following the same steps (creating the database tables then create the associated classes using EF).
And I am interacting with these classes on the same way, for example I used to query the User class using the same syntax and approach but one time when the User class was created using Linq-to-SQL and the other time when it was created using EF, so where is the difference ?
public IQueryable<User> findstudents(string term)
{
return from student in entities1.Users
where student.UserID.Contains(term)
select student;
}
Second question if I use EF to map the tables into classes, is it still possible to use Linq-to-SQL in the same application to query the EF classes?

LINQ is a base technology - that's the syntax that gives you the SQLish query options in C# - that's totally independent of whether you use Linq-to-SQL or EF. So if you want to query your data classes using the LINQ syntax - you can do that with both frameworks - but once you use Linq-to-SQL and once you use Linq-to-Entities. You cannot use Linq-to-SQL against an Entity Framework EDMX model.
Linq-to-SQL is great
if you need very simple 1:1 mapping - one table equals one class in your domain model
if you never need anything else but SQL Server (Linq-to-SQL doesn't support anything else)
if you want to be up and running really quickly
Entity Framework on the other hand
supports multiple backends (SQL Server, Oracle, Firebird - other will likely follow)
supports a full conceptual data modelling strategy - you define the physical model in the database, the conceptual model in your app, and the mapping between the two
gives you the ability to handle things like mapping a single business entity to several tables
support table-per-hierarchy and table-per-class inheritance scenarios
support refreshing/updating your model (EDMX file) from the database when things change (in Linq-to-SQL, you basically have to drop + recreate those entities involved - thus loosing all your customizations you might have made)
In brief: Linq-to-SQL is a great, simple and lean'n'mean ORM for SQL Server - use it, if it does all you need. Entity Framework is quite a different beast, much more capable, but also more complex, much bigger - perfect for your next enterprise-critical app, but probably overkill for your personal blog app :-)
If you want to create something that's "future-proof" and will use the OR technology that Microsoft is pushing into the future, then you should go with Entity Framework. Especially in v4, it's also a lot easier to use, a lot more slimmed down and more useful than ever before.

Need Advice: Switching from Linq to SQL to Entity Framework

I know the high-level differences between linq to sql and entity framework, however, I am hoping for advice from someone else who has already made the switch themselves, or has sufficient experience with both. Coming from a strong linq to sql background, as far as implementation and low-level details, are there any important things I need to know as I start coding my new data access layer project with entity framework?
I already created my edmx file (I chose the database-first approach), and everything just seems suspiciously identical to linq to sql so far. What would help me is a short list of items, like, in linq to sql, you do [this] [this way], but in entity framework, you'll want to do it [this way].
Sorry if this is a strange question, but any attempts at answers would be greatly appreciated. Thanks!

In new project between L2S and EF I suggest EF (consider Entity Framework version 4.0 or superior, DON'T use early EF releases).
While Linq to SQL is a class to table mapping EF 4 is a complete ORM (Object Relational Mapping) tool with different mapping scenarios.
With EF you have a lot of flexibility:
Database First approach
Model First approach
Code First approach
and a strong integration with LINQ Provider.
Unit testing with Linq2SQL is a nightmare.
With EF you have POCO (Plain Old CLR Object) classes out of the box. In L2S the entity class is tight coupled to the L2S namespace.
EF can help you also in Domain Driven Design scenarios.
Microsoft consider now EF the first database access method and it's the base for other services like RIA services or MVC database scaffolding.
LinqToSql is now the first database access methodology only in Windows Phone scenarios.

NH is far better... but again as EF is microsoft baby, it will grow as time goe

Does Linq Remove The Need For Hibernate?

Just wondering whether anyone will still use Hibernate once they move to C# 3
Are these mutually exclusive??

It's important to note that Linq is not just an ORM tool. There is also Linq-To-XML and Linq-To-Objects to name two but there are more. Linq is a set of language extensions to C# and VB that give you syntactic sugar when dealing with object collections.
As to your main question, Linq-to-SQL is fine if you have a one-to-one mapping from tables to domain objects. Where NHibernate comes into it's own is where you have an existing complex domain model or existing complex database schema and you want to map between them.
Additionally, it's possible to use both with Linq-To-NHibernate.

Linq is more about making a uniform way in which one can query DB, XML, Objects or any custom data store. Hibernate is only for querying DBs.
You can use Hibernate instead of Linq-to-SQL in case you are more proficient and comfortable in that Linq provides pretty much the same powerful ways to query DB as Hibernate. So in a way when restricting our discussion to DB, Linq can serve you the same (or a large majority of!) purpose as Hibernate.

I think more people would use NHibernate if it could compete with Hibernate. That being said, NHibernate is generally not needed in a .net shop.

The existance of Linq To NHibernate alone, proves not.

Your terminology is off. LINQ is just syntactic sugar for manipulating data. Linq to Sql is probably what you're talking about.
IIRC Linq to Sql only supports MSSql (apparently they intentionally killed off compatability with other db providers, I have no idea why, some speculate anti-competition, others state a deadline turned up so they just culled what wasn't ready). So no chance of NHibernate being irrelevant here.
The Entity Framework (MS's ORM tool that supports all databases). When this initially came out some of the ORM community hated it, it didn't support "persistence ignorance" and a number of features, concepts and premises the community expects from a modern ORM. I believe they are working to improve it but they have a lot of catching up to do to get close to NHibernate IMO.
So no, NHibernate is still massively relevant if you want fine control over your ORM. It is one of the most flexible yet complex ORMs about and therefore still has its place.

I dont like linq-to-sql (since that is what you mean) that much since you have to design a database schema. With hibernate (although i use a similar product named XPO) you just make your objects and the framework takes care of the relations (one-to-one, many-to-one, M-To-M).
THat is the big disadvantage of linq to sql. So no, they're not mutually exclusive.

Linq to SQL for a new project

I am about to start a new project and am deciding what data access technology I will be using... I really like LINQ to SQL for a variety of reasons but should I start the new project using the Entity Framework instead??
I have this perception that the Entity Framework is more bloated and needlessly complicated, thus accounting for part of the reason I was thinking about going with LINQ to SQL... but as I said this may only be perception on my side as I haven't used the Entity Framework all that much.
So which would people recommend I use for starting a new project today (note this app will be around for years to come)?
Cheers
Anthony
EDIT:
We are SQL Server shop so we don't need database vendor independent.
Also is the generally agreed best way to abstract data access atm by using the Repository pattern which works with my domain objects?

LINQ to SQL is about rapid development and simplicity. If your data model is complex, or might become so, you will be better off using a more robust framework.
That said, more important than your data access tool is how well you abstract it from the rest of your code. Done right, you should be able to start with LINQ to SQL and switch when you outgrow it (or when EF 2 4 comes out).

Note that EF 1 is far from complete. It lacks all kinds of features you do find in LINQ to SQL, one of the more important ones being actual foreign key properties (can you imagine these don't exist in EF 1?)
Also, EF 4 will pretty much have all features of LINQ TO SQL, and both will generate relatively comparable (code wise) external API, so unless you're coding to very LINQ to SQL specific API's, it should be relatively easy to migrate to EF4 later on, 'simply' by replacing the LINQ to SQL .dbml with EF4's equivalent.

Linq to SQL works best in an active record / one table per class paradigm. If you need to span your class across several tables, or support complex inheritence then it may not be the best choice. Also, Linq to SQL doesn't natively support many-to-many relationships (there are workarounds).
If neither of those sound like they'd affect you, then Linq 2 SQL may be a good choice. It's a great lightweight data access strategy.
Linq to SQL can be used to implement the repository pattern very well given the above constraints. Google will turn up several viable Linq repository examples.

Have you taken a look at Subsonic - now in version 3 it is basically a linq to sql DAL that makes it possible to have full linq to sql of your entire database in under 5 mins. And it runs off T4 templates, so if you want to add to the templates it is REALLY EASY
http://www.subsonicproject.com/

I wrote up a pretty lengthy blog post on choosing a .NET ORM:
.NET and ORM - Decisions, decisions
Basically, NHibernate is your best bet. If you insist on something with simplicity like LinqToSql, consider SubSonic. I would not recommend either of the Microsoft options: LinqToSql or EntityFramework.
Deciding whether to use the repository pattern or not is situational depending on your requirements.

Check out: http://www.icemanind.com/Layergen.aspx

LINQ or ADO.net Entity Framework - which to learn?

A bit of a clarification: I was browsing Julia Lerman's Oreilly title on Entity framework and I got mighty confused.
I have Charlie Calvert's essential LINQ, but from my 10 minute session with Lerman's book, it transpires that LINQ is LINQ to SQL which seems underpowered with its DataContext object etc...
Whereas Entity Framework is the future, but it has something called Entity SQL which to my eye looked exactly like Transact-SQL. Now my eye could be a bit rusty, but the question is:
Since Entity Framework is the main horse that Microsoft is backing, is there any point in learning LINQ to SQL with its
var numberGroups =
from n in numbers
group n by n % 5 into g
select new { Remainder = g.Key, Numbers = g };
And am I confused in thinking that Entity SQL and LINQ are two different technologies, does entity SQL in fact use LINQ?
post the many replies I got:
Ok Folks, I'm new to this, so I'm editing my answer this time ;-)
Many thanks for your full, expedited and very helpful answers.
Regards
MereMortal

LINQ != LINQ-to-SQL
LINQ is the concept, including some language support. There are many implementations - LINQ-to-SQL is one, as is ADO.NET Data Services, Entity Framework's LINQ-to-Entities, LINQ-to-Objects, LINQ-to-SQL, LINQ-to-Amazon, DbLinq, etc.
You still use LINQ with Entity Framework; indeed, LINQ-to-Entities is the preferred choice, giving compile time static checking. Entity SQL is simply another mechanism (in addition to LINQ-to-Entities) for querying the EDM (Entity Data Model).
There are 3 main reasons that ESQL is useful:
it was the only option in early previews when LINQ-to-Entities was still under construction
it can be used in some scenarios where there is no object model, for example reporting services
there is a small number of cases where ESQL is more expressive
For everything else, LINQ should be your tool for working with Entity Framework.

LINQ is a generic term for the language features that permit queries to be written in C# or VB.NET over a data store of some sort. There is LINQ to SQL, LINQ to Entities, LINQ to Objects, etc.
LINQ to SQL closely models the physical database structure. It produces one type for every table in the database. If your database changes, then your LINQ to SQL code will need to change.
LINQ to Entities more closely models the conceptual database design. It allows you to map to the physical database, but for instance, allows you to create one Person entity that includes data from both the Person and Contacts tables. This allows your callers to think in terms of what the data mean instead of how the data are implemented.
Also, Microsoft has said that future development in LINQ to SQL will be limited when compared to the development in LINQ to Entities. Given the increased flexibility and the fact that LINQ to SQL won't get many more enhancements, I'd go with LINQ to Entities and Entity Framework.

As others said, you probably mean Linq to SQL vs Entity Framework.
Both work for SQL Server, but only Entity Framework will work for other databases. Also, LINQ to SQL has, more or less, been depreciated. So go with Entity Framework.

Linq is a programming construct that allows you query your objects
there is a Linq to Sql that I think you are talking about.
you can always use linq to query EF objects...

Whoa whoa. Slow down there.
Short Answer: Entity Framework
Longer Answer:
LINQ to SQL and Entity Framework are data access technologies.
Linq is, according to MS,
LINQ is a set of extensions to the .NET
Framework that encompass
language-integrated query, set, and
transform operations. It extends C#
and Visual Basic with native language
syntax for queries and provides class
libraries to take advantage of these
capabilities.
from : http://msdn.microsoft.com/en-us/netframework/aa904594.aspx
Both LINQ to SQL and Entity Framework have Linq providers, which allow for that awesome syntax when querying against them.

Entity Framework has LINQ to Entities, so you can execute very the same query against EF as well. And my answer will be invest more to EF, because upcomming EFv4 seems promissing.

From what I understand, EF is not quite ready for prime time yet, and it does not support many of the LINQ constructs that work so easily today in LINQ2SQL.
If you can commit to SQL Server for your application, I say today, learn LINQ2SQL. You'll have more capabilities in querying when using LINQ.
I'm betting when EF is ready, it'll be a much easier transition for you since the query language should be transferrable.
Good luck.

I go in microsoft TehcDays in Montreal on december 2 and 3, and they said, that they will no longer support LINQ to sql in few year, so your better start to learn LinQ to entity (Entity framework).