My understanding so far is :
Entity Framework make it easier to use LINQ to SQL. It generate the entity types for us automatically.
I just started to learn LINQ. So the above statement is very likely to be wrong. Could you share your thought?
There is no relationship between Entity Framework and Linq to Sql. They're two totally different technologies.
Entity Framework is more advanced, and requires a bit more knowledge to get up to speed than Linq to SQL.
Linq to SQL is no longer being updated by Microsoft, and their forward direction is Entity Framework. however Linq to SQL is still supported.
Related
I know ASP .Net and ADO .NET But I am really confused with this Entity Framework and LINQ.
Can We Use Entity Framework to Interact with Db without like ADO .NET.Are all these three (ADO ,Entity framework,LINQ) is alternative to each other ?
Please guide
Here is my best explanation (after hours of confusion!):
ADO.NET = Part of the .NET framework enabling you to easily access data and data services like Microsoft SQL Server
LINQ (Language-integrated query) = Enables you to query data from within .NET programming languages
LINQ has been integrated in various areas of the .NET framework including:
LINQ to Objects
LINQ to XML
LINQ to ADO.NET
LINQ to ADO.NET = enables you to query over any enumerable object in ADO.NET by using LINQ
There are 3 LINQ to ADO.NET technologies:
LINQ to DataSet = enables you to write queries against the DataSet (a class that represents an in-memory version of a DB)
LINQ to SQL = enables you to write OO queries in your .NET project that targets SQL databases. It translates LINQ queries into SQL statements. This is no longer supported by Microsoft due to the great overlap in functionality with the Entity Framework (EF).
LINQ to Entities = Almost anything you can do in LINQ to SQL can be done in LINQ to Entities. Enables developers to write queries against the Entity Framework(EF) conceptual model using VB or C#.
EF is an Object Relational Mapper (ORM) that supports the development of data-oriented software applications. With EF, you can take a bunch of database objects like tables and turn them into .NET objects that you can access in your code. You can then use these objects in queries or use them
directly in data-binding scenarios. EF also enables you to do the reverse: design an object model first and then left EF create the necessary database structure for you.
Source: Beginning ASP.NET 4.5.1, Microsoft Documentation
I assume that by LINQ you actually mean LINQ to SQL.
EF (Entity Framework) and L2S (LINQ to SQL) are object-relational
mappers that use ADO.NET internally, encapsulating most of its functionality. So if you use either, you'd still be using ADO.NET.
All three are viable options for building the data access layer or your code, with their own strengths and weaknesses. Have a look at this post for more info:
Entity Framework VS LINQ to SQL VS ADO.NET with stored procedures?
I've got an Oracle database that I access through Entity Framework and I am seeing a performance hit on selects where I hit tables with CLOB columns in them.
If I break out the query generated by Entity Framework I get similar results when simply calling ExecuteReader using an OracleCommand, but I can improve performance a lot by setting InitialLOBFetchSize to -1 on the OracleCommand.
I would like to do the same for Entity Framework.
How do I tell Entity Framework to set InitialLOBFetchSize to -1?
This is for Entity Framework 4.
I had the same problem few years ago and I ended up using a wrapped OracleConnection, OracleCommand, DbProviderFactory and other ADO.NET classes, and Entity Framework provider so any operation EF does with instances of these classes I was able to inject any functionality in or change the command or connection configuration.
I'm starting work on a Custom Membership provider and I was wondering which option would be the best to develop this application in Linq or Entity Framework?
Also I have a need to link two table from different database via a common ID and I was wondering does anyone know of any good tutorials about creating a MVC 3 Web Application that uses either Linq or Entity Framework to do this.
From my research Entity Framework seems to be the best method suited to my situation but I would appreciate some advice / confirmation that this correct and a little direction to a tutorial is possible?
By Linq, you mean Linq to SQL vs. Entity framework? If so, then I would recommend using Entity Framework. Microsoft's development on Linq to SQL has virtually stopped so EF has a better future.
NerdDinner is one of the more popular tutorial applications that uses ASP MVC 2 and entity framework. ASP MVC 2 is similar enough to get started with the basic concepts. Here is a good walk through tutorial:
http://nerddinnerbook.s3.amazonaws.com/Intro.htm
The code itself is freely available:
http://nerddinner.codeplex.com/
How to choose that which ORM would be feasible for a web Application? e.g if we are using Linq then why not nhibernate? and Which one is better and why
Every ORM that claims linq support, supports linq to a degree, however the completeness of the implementations vary greatly, sometimes because of the way the ORM is implemented, sometimes because of the quality of the Linq implementation.
Even the Linq implementations between Linq to Sql and Entity Framework v4 vary greatly, if you then look at NHibernate's or LlblGenPro's implementations you will find there are queries that are possible in sql that each doesn't support in the same way, if at all, or that the support with different levels of efficiency.
You really need to evaluate the particular ORM's Linq implementation against the type of data retrieval you tend/want to do.
I think a lot would depend on the application you are building.
On the other hand, NHibernate is very powerful and can be customized to do just about anything. We recently dumped our old ORM and moved to NHibernate because we just couldn't do what we needed to do without it.
You can use Linq with nHibernate. But take the most popular ORM. The one the most developers use.
It will be easier to find a developers to maintain and enhance the project and it will be easier to find solutions to your problems on Google.
I'm still using nHibernate but new versions of Entity Framework look promising.
I will switch when Entity Framework will become as powerful as nHibernate.
I have used the Entity Framework to start a fairly simple sample project. In the project, I have created a new Entity Data Model from a SQL Server 2000 database. I am able to query the data using LINQ to Entities and display values on the screen.
I have an Oracle database with an extremely similar schema (I am trying to be exact but I do not know all the details of Oracle). I would like my project to be able to run on both the SQL Server and Oracle data stores with minimal effort. I was hoping that I could simply change the configuration string of my Entity Data Model and the Entity Framework would take care of the rest. However, it appears that will not work at seamlessly as I thought.
Has anyone done what I am trying to do? Again, I am trying to write an application that can query (and update) data from a SQL Server or Oracle database with minimal effort using the Entity Framework. The secondary goal is to not have to re-compile the application when switching back and forth between data stores. If I have to "Update Model from Database" that might be ok because I wouldn't have to recompile, but I'd prefer not to have to go this route. Does anyone know of any steps that might be necessary?
What is generally understood under the term "Persistence Ignorance" is that your entity classes are not being flooded with framework dependencies (important for N-tier scenarios). This is not the case right now, as entity classes must implement certain EF interfaces ("IPOCO"), as opposed to plain old CLR objects. As another poster has mentioned, there is a solution called Persistence Ignorance (POCO) Adapter for Entity Framework V1 for that, and EF V2 will support POCO out of the box.
But I think what you really had in mind was database independence. With one big configuration XML that includes storage model, conceptual model and the mapping between those two from which a typed ObjectContext will be generated at designtime, I also find it hard to image how to transparently support two databases.
What probably looks more promising is applying a database-independent ADO.NET provider like the one from DataDirect. DataDirect has also announced EF support for Q3/2008.
http://blogs.msdn.com/jkowalski/archive/2008/09/09/persistence-ignorance-poco-adapter-for-entity-framework-v1.aspx
The main problem is that the entity framework was not designed with persistence ignorance in mind. I would honestly look at using something other than entity framework.