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
Related
Except for Entity Framework, which ORMs can generate classes from an existing database?
I am looking to move away from Entity Framework because it is just too slow. I am wondering which ORMs out there are going to be the easiest to migrate a fairly complex WCF service to (from Entity Framework and an Existing Database).
Not sure if it will work for you, but I have migrated from EF to dapper with great results. As far as generating code, dapper doesn't do it, but using a tool like codesmith or t4 you can quickly get a lot of your run of the mill classes generated.
If performance is your top concern, youd have a hard time beating dapper.
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 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.
We currently have a solution that was completely written by hand in ASP.NET and MVC.
There are a lot of ugly hacks and workarounds in the DAL currently and rather than expand on these hacks, I've managed to convince the suits that we need to migrate to an ORM of some sort.
With Entity Framework experience in the team, we've decided to go with the Entity Framework, however, I have a migration question for anyone who may have had an experience with this.
Would there be any performance issues if we were to migrate Entity-by-Entity until everything was migrated to EF? What possible roadblocks (other than the obvious of having to rewrite most of the BL) could we face? Should it literally be done Entity-by-Entity (in terms of, creating the models) or would there be issues creating the entity model and just changing the BL bit-by-bit.
I can't seem to find any documentation on the subject.. MSDN seems to just say "Yay Entity Framework is good, so migrating to it is good.".
Any advice would be appreciated.
PS: I did read this: Migrating from 'native' OODBMS to ORM (Entity Framework / SQL Server)
However as we've decided to go with EF instead of NHibernate, it didn't prove very useful.
It's good question and i have a answer from my prospective. It's about 'Yay Entity Framework is good, so migrating to it is good'
Now our team is working over big (very big) HR SaaS solution. From the beginning we decided to use:
EF 4.1
MySQL (that was requirement from client)
.NET MVC 3
Then time passed (near 3 weeks) we noticed next about EF: using Model first is not applicable and useful in our system in case of hard to support system in future when we need, for example, change a little bit db structure or make new relations between tables.
In this case we moved to EF Code First (with one generic repository for all db requests). That was the risk cause it's so new technology and there was no best practices or use cases on big solutions. As result we recived a lot of other headache:
ORM made a lot of db requests (cause of a lot of relations between tables). Fixed by .Include()
Dynamic Proxy for POCO objects - made a lot of troubles, cause in code first entities from db came not like requested entity type - like dynamic proxy type. So when we tried to serialize them and put to Memcached on deserialization we get the error that this entity no more available in current context. Fixed like this: http://msdn.microsoft.com/en-us/library/dd456853.aspx and this: http://blogs.dotnetkicks.com/dpeterson/2011/08/11/theres-a-proxy-in-my-boots-entity-framework-poco/
Stupid bag with Membership that sent a lot of unbelievable requests. Fixed by reviewing our work with Membership
Also we tried NHibernate to just compare performance. NHiberanate has the same :)
General info that you should know about EF:
If you want to attache 3rd part caching be ready for workaround. NHibernate have a native integration of this
There is no big different between EF and Nh performance, but Nh have a lot of hand work with mapping
Hope i answer to your questing and info is relevant for you.
ps> sorry for my English :)
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