Confused with Ado .net, Entity Framework,LINQ - linq

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?

Related

ASP.NET Boilerplate Framework with ADO.NET

How to use ADO.NET with the multi tenant application. I would like to to use ado.net with SQL server. please advise if there are any samples.
Just create a custom repository and use SQL inside it.
Check this article for more: http://www.aspnetboilerplate.com/Pages/Documents/Articles/Using-Stored-Procedures,-User-Defined-Functions-and-Views/index.html
It also uses SP and views.
Your choices are:
EF Core
EF
Dapper
NHibernate
If performance is top priority for you Dapper may be of interest.

Is Oracle NOW fully supported by .NET entity framework?

I was having trouble finding a path/resource to the query if oracle is supported by Entity framework.
If it does ... which of the following Workflows does it support?
Model First
Database First
Code first(new database)
Code first (Existing database)
Kindly also mention the resource where I can learn Entity framework that has support for oracle.

Relationship between LINQ to SQL and Entity Framework

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.

How to choose that which ORM would be feasible for or Application? e.g if we are using Linq then why not hibernate

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.

How to Implement Database Independence with Entity Framework

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.

Resources