I'm an ASP.NET n00b and I read in my ASP.NET book that your C# LINQ code gets made into actual SQL queries when you compile your project. I can't find anything on the internet to verify this; however, if it's true, I'm wondering if stored procedures are created from LINQ queries; and if not, what's the point of LINQ? I'm confused about why someone who knows how to write SQL would invest time learning something that's "valid C# and looks like SQL but isn't quite SQL" ...
I saw a related thread LINQ queries vs Stored procedures but it was written in 2011.
No, LINQ queries to databases do not get converted to stored procedures. They would be converted to SQL if the underlying database language is SQL, for example SQL Server / Oracle.
You are confusing ORM and LINQ. LINQ is more than querying database. It is also about querying general collections like arrays/List<T> (IEnumerable<T>).
Adding to above answer, LINQ is feature of .NET Framework which are strongly typed which aren't specific to Entity Framework (ORM) and even INDEPENDENT to database. There are different LINQ provider i.e. LINQ to Entities is responsible to translating LINQ to appropriate query on data and get result back.
So this will shine for someone who don't know SQL yet and who wants to deal table and data in terms of object.
Related
Does anyone know if you can use LINQ techniques for querying a Microsoft Access database? In my online searches for this question, I have gotten mixed reviews. Some have said it's 'sort of possible' while others say LINQ can only be used with an SQL server database.
Does anyone know the definitive answer on this?
LINQtoSQL can only be used with a SQL Database.
Entity Framework can work with SQL or Access.
LINQtoEntities can work with the Entity Framework.
General LINQ methods can work with IEnumerables regardless of how they were populated.
I have gone through an article of using EntityConnection, EntityCommands for executing Entity sql queries. But I was unable to understand that Why are we using Entity sql? Why not directly using the Classes and objects for processing CRUD operations on database?
Or If we want to execute sql queries then why we are using Entity Sql , why not directly Ado.net ?
Is there any performance difference or something else?
I have already gone through the page http://msdn.microsoft.com/en-us/library/bb738573.aspx. But I want answer in a more simpler way. Can you please answer me?
Thanks
Why not directly using the Classes and objects for processing CRUD operations on database?
That is (should be) the way for almost all operations. But sometimes there is a need for accessing the db more directly and precisely.
If we want to execute sql queries then why we are using Entity Sql , why not directly Ado.net ?
E-SQL will still let you work with entities (instead of Rows). This is much easier and more powerful, consider inheritance for example.
E-SQL is also supposed to be independent of the actual database, ie the same for Oracle etc. I have no experience with this yet.
Is there any performance difference or something else?
It can be used to improve performance, yes. But not automatically.
The main difference
SQL is database dependent query language working on storage (relational) objects - tables / rows
ESQL is database independent query language working on conceptual (EDMX) objects - entities
ESQL was created prior to LINQ. In some scenarios ESQL offers more functionality than LINQ.
I am building a forum, and it has got 4 tables: Users, Threads, Comments, Topics.
I established the connection and the pages.. I started using the ADO.net way to insert data and select data..but then I found that to make more complex manipulations i need to know SQL. So I was looking for another way, and I found that I can open Visual Studio 2010, add Linq to SQL file that produced object relational designer. I read about how to write code, and I saw that I simply need to use a using statement with DataContext object with a simple code to update, add, delete rows in the tables.
I wanted to know, what are the advantages of using one way of querying over another?
ADO.NET gives you low level control over your queries. If query speed is going to be of importance, this is where you want to be. If you speed is not very important, but rapid development and an Object Relational Model is, LINQ to SQL is a safe bet.
I would recommend Linq to SQL over ADO.NET though.
Development is rapid and thinking in an ORM way is natural.
If your queries are too slow, using the .ExecuteQuery method will allow you to pass in a sql statement that you have optimized as if you were doing it in the ADO.NET way. I have had much success with Linq to Sql.
Also I would look at Entity Framework. It gives you more control over your objects and how they are implemented, used and handled than Linq.
LINQ to SQL is part of the ADO.NET family of technologies. It is based on services provided by the ADO.NET provider model. You can therefore mix LINQ to SQL code with existing ADO.NET applications and migrate current ADO.NET solutions to LINQ to SQL. The following illustration provides a high-level view of the relationship.
Refer to the following:
ADO.NET and LINQ to SQL
Advantages & Disadvantages of LINQ
Performance of LINQ to SQL over Normal Stored procedure
LINQ-to-SQL and Stored Procedures
LINQ to SQL is great in that it generates alot of the plumbing code for you. But it is basically the same as using straight up ADO.NET/SQL. To do more complex data manipulation in LINQ to SQL you have to know how write complex joins in LINQ just as you would in SQL.
Look into Entity Framework - it might give you a higher level of abstraction that you are looking for.
The two are on different abstraction levels. ADO.NET is the lowest level of data access in .NET. Anything else will build upon it.
Every abstraction should give you power to express higher-level concepts at the cost of lower level concepts.
If I sound like a philosopher it's because it's Friday.
In addition to Entity Framework, you can take a look at NHibernate (another .net Object Relational Mapper). It's been around longer than EF so it's a bit more mature, but it isn't developed by Microsoft if that matters to you.
I've been working for quite a while now with LINQ. However, it remains a bit of a mystery what the real differences are between the mentioned flavours of LINQ.
The successful answer will contain a short differentiation between them. What is the main goal of each flavor, what is the benefit, and is there a performance impact...
P.S.
I know that there are a lot of information sources out there, but I'm looking for a kind of a "cheat sheet" which instructs a newbie where to head for a specific goal.
all of them are LINQ - Language Integrated Query - so they all share a lot of commonality. All these "dialects" basically allow you to do a query-style select of data, from various sources.
Linq-to-SQL is Microsoft's first attempt at an ORM - Object-Relational Mapper. It supports SQL Server only. It's a mapping technology to map SQL Server database tables to .NET objects.
Linq-to-Entities is the same idea, but using Entity Framework in the background, as the ORM - again from Microsoft, but supporting multiple database backends
Linq-to-DataSets is LINQ, but using is against the "old-style" ADO.NET 2.0 DataSets - in the times before ORM's from Microsoft, all you could do with ADO.NET was returning DataSets, DataTables etc., and Linq-to-DataSets queries those data stores for data. So in this case, you'd return a DataTable or DataSets (System.Data namespace) from a database backend, and then query those using the LINQ syntax
LINQ is a broad set of technologies, based around (for example) a query comprehension syntax, for example:
var qry = from x in source.Foo
where x.SomeProp == "abc"
select x.Bar;
which is mapped by the compiler into code:
var qry = source.Foo.Where(x => x.SomeProp == "abc").Select(x => x.Bar);
and here the real magic starts. Note that we haven't said what Foo is here - and the compiler doesn't care! As long as it can resolve some suitable method called Where that can take a lambda, and the result of that has some Select method that can accept the lambda, it is happy.
Now consider that the lambda can be compiled either into an anonymous method (delegate, for LINQ-to-Objects, which includes LINQ-to-DataSet), or to an expression-tree (a runtime model that represents the lambda in an object model).
For in-memory data (typically IEnumerable<T>), it just executes the delegate - fine and fast. But for IQueryable<T> the object-representation of the expression (a LambdaExpression<...>) it can pull it apart and apply it to any "LINQ-to-Something" example.
For databases (LINQ-to-SQL, LINQ-to-Entities) this might mean writing TSQL, for example:
SELECT x.Bar
FROM [SomeTable] x
WHERE x.SomeProp = #p1
But it could (for ADO.NET Data Services, for example) mean writing an HTTP query.
Executing a well-written TSQL query that returns a small amount of data is faster than loading an entire database over the network and then filtering at the client. Both have ideal scenarios and plain-wrong scenarios, though.
The goal and benefit here is to allow you to use a single, static-checked syntax to query a wide range of data-sources, and to make the code more expressive ("traditional" code to group data, for example, isn't very clear in terms of what it is trying to do - it is lost in the mass of code).
LINQ stands for language integrated query. It allows you to use "SQL style" query language directly within C# to extract information from data sources.
That data source could be a SQL server database - this is Linq to SQL
That data source could be an data context of entity framework objects - Linq to entities.
That data source could be ADO.net data sets - Linq to Dataset.
That data source could also be an XML file - Linq to XML.
Or even just a Collection class of plain objects - Linq to Objects.
LINQ describes the querying technology, the rest of the name describes the source of the data being queried.
For a bit of extra background:
Datasets are ADO.net objects where data is loaded from a database into a .net Dataset and Linq can be used to query that data after it's loaded.
With Linq to SQL you define .net classes that map to the database and Linq-to-SQL takes care of loading the data from the SQL server database
And finally the Entity framework is a system where you can define a database and object mapping in XML, and can then use Linq to query the data that is loaded via this mapping.
Is LINQ to Dataset subset of LINQ to EF or these two are independent?
They are independent.
Linq to Dataset works against a DataSet that was previously created using ADO.NET. The dataset is loaded prior to using linq, so the SQL queryies are not build dynamicly.
Linq to EntityFramework works against entity framework context. Here the SQL queries are constructed dynamically, based on the Linq query you provided.
Linq works with the concept of queryProviders.
The query provider is responsible for translating the lamba expressions into queries on the underlying data store.
as Obalix said before me Linq to Entities query provider translates the linq with lambdas into real sql which is executed using underlying ado.net objects. Take a look at canonical functions here, which are translated into sql (and take notice which are not).
On the other hand linq to dataset works against DAtaSet infrastructure. As you may remember Data Set has some queries associated with it. (getters, updates, deletes, inserts) with the usage of the DataAdapters objects. Linq queries are mapped onto objects that already exist in the dataset = tables, columns etc. The SQL queries are not built, because the provider does not operate at such a low level - the data set is the data abstraction it uses.
You might take a look at linq to SQL if Database agnosticism is not You concern, and there is even some provider linq to Oracle if I heard correctly.
They are independent and don't even work together very well.
LINQ-to-Datatsets is a set of extension methods that allows LINQ queries against data already loaded into DataTables, based on IEnumerable. It is close to querying List<> and other collections.
LINQ-to-Entities uses query providers and IQueryable to translate LINQ queries into SQL queries. It also provides for modeling of the database tables as objects.
If you use EF you are able to write (much more) Object Oriented, using DataSets remains Database Oriented.