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).
Related
I know the benefit of the LINQ and I know use of it in .Net Application. I fill same thing there are providing as a Entity Framework.
So What's Major Difference between LINQ and Entity Framework?
LINQ could be applied to any data source: in-memory objects, XML, SQL, ...
Entity Framework could use LINQ to perform queries against a relational database.
LINQ to SQL is the predecessor of Entity Framework and is obsolete now.
Comparing EF and LINQ is incorrect. Both are different things and they often work together to give better developer experience (and productivity benefit).
LINQ is querying syntax/model that can be applied to any data source. EF provides one such data source.
They are somewhat similar, and can be used in a very similar way, code-wise, but they have some important differences. Note that "LINQ" is not the same thing as "LINQ to SQL"; the EF also uses LINQ. Some notable differences are:
LINQ to SQL is largely SQL Server only, not so much by design as by implementation. The EF is designed to support, and does support, multiple DBs, if you have a compatible ADO.NET provider.
Out of the box, LINQ to SQL has a very poor story for DB metadata changes. You have to regenerate parts of your model from scratch, and you lose customizations.
The EF supports model features like many-to-many relationships and inheritance. LINQ to SQL does not directly support these.
In .NET 3.5, LINQ to SQL had much better support for SQL-Server-specific functionality than the EF. This is mostly not true in .NET 4; they're fairly similar in that respect.
The EF lets you choose Model First, DB First, or Code First modeling. LINQ to SQL, out of the box, really only supports DB First.
SOURCE : Here
I totally agree with VinayC. You cannot really compare.
With Entity Framework, you will be able to have a whole representation of your database in your program. It will help you create classes corresponding to the database elements, connected together like they are in the database. You can after interact with elements of theses classes directly, and like this impact the database. You will have some representation of these classes diagram in visual studio. It's basically often simpler than working directly with the database elements, even if setting it up requires some effort.
The use of Linq is to perform queries on the data sources.
I am working on window application developed using SCSF and we are using sybase database. As practise we create typedataset in the .net project and then populate them using framework method and for all the sql statement we write stored procedure in the database.
So we have type dataset in memory so I am using linq to select records from datatable. Can I step one step further and use something related to Entity Framework?
Can it reduce my work? I don't have hands-on experience with Entity Framework but can you suggest something in this scenario?
Thanks,
Denish
Entity framework uses similar concepts as the type datasets except for:
The ability to have a class structure that is not exactly the same as the table structure (e.g. class hierarchy, splitting tables into multiple classes, joining tables into one class).
The ability to use LINQ to perform queries in the database instead of in memory.
Entity framework also lets you map results of stored procedures to classes and bring results into memory if you need to run a query that is faster in memory or not translatable to SQL.
For most SQL queries the LINQ to Entity will be effective enough, so you will probably end up writing less stored procedures.
You will have to learn how to use EF and LINQ effectively and use can use 3rd party tools such as Entity Framework Profiler to help you.
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
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
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
Is LINQ to SQL DOA?
I am starting a new ASP.Net project which holds all data in a SQL database. I would normally use Linq to SQL to do all my queries, updates and inserts. but as i recently found out Microsoft will no longer develop/support Linq to SQL. What would you use as an alternative?
Does anyone know why they are dropping this, as I have come to like Linq to SQL, and do you know what they will replace it with?
Any information would be great.
Linq to SQL is not dead nor is it being replaced with EF, they have not killed it, feel free to compare and contrast
Linq to SQL
Entity Framework (aka Linq to Entities)
nHibernate or any other ORM
Pick one that works for you and stick with it, neither are dying.
FWIW, Microsoft has more developers working on Linq to SQL than it has working on MVC.net right now
I prefer Linq to SQL because I do not need to support non MSSQL db and its much lighter than EF. It doesn't support every last thing you'd need, but in my opinion (and I may get flamed for this) Linq to SQL is to MVC.net as EF is to webforms.
EF obviously has its advantages over Linq to SQL though, there are somethings that linq to sql just flat out doesn't support (cross db joins, non mssql databases, creating a type based on a view, etc). Every tool has its place.
Some decent comparisons on the two
Oh and StackOverflow was built with linq to sql
if you use ANY technology, prepare for it to eventually fall from favor, and not be the latest technology!
if you don't pick Linq, whatever you use will eventually be "old", and people will be asking if it is worthwhile to learn or use, since there are better things out.
if you are writing software prepare to keep learning new tech and methods, or switch careers.
If you like Linq 2 Sql, then I recommend you try out SubSonic as it works very much like Linq 2 Sql. It's lightweight and your wrapper classes are generated from an existing database. I believe the next version of SubSonic will be supporting Linq as well.
Microsoft is now pushing the Entity Framework in lieu of Linq to SQL:
http://blogs.msdn.com/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
MSDN Info on Entity Framework:
http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx
Update:
More complete list of Entity Framework Resources:
http://blogs.msdn.com/wriju/archive/2009/03/10/ado-net-entity-framework-resources.aspx
And of course the obligatory O'Reilly book on the subject:
http://fyi.oreilly.com/2009/02/introducting-the-adonet-entity.html
Linq to Entities will replace Linq to SQL.