I have some confusion that, In Linq-to-Object we work in-memory data to execute LINQ query that is process by c# language.
When i write a Linq query that is execute base on in-memory data why we use provider (LINQ-to-Object)?
No, Linq to Object IS NOT A PROVIDER and it doesn't have to relay on any other intermediate provider to run query(linq to object).
To understand it more clearly, we have to understand what provider actually is. Provider is basically the implementation that implements IQueryProvider and IQueryable interface and this mainly translates your linq query to SOMETHING that your provider understands. For example, when you go for LINQ to SQL queries your queries converted/translated into SQL, its get translated into SQL because your provider (in this case) only understands SQL.
When you run query against In-Memory collection of data, C# don't have to translate your linq query to other query.
As #Stilgar mention "Providers are used when the source is IQueryable". When you are working against In-Memory data, your source is basically IEnumerable.
LINQ to Objects is not a LINQ provider. It is an implementation of the LINQ API on IEnumerable. The LINQ API can be implemented on practically any type as long as you name your methods properly and accept the proper arguments. That being said there is something very close to a LINQ provider related to LINQ to Objects. Providers are used when the source is IQueryable and the compiler produces an expression tree. An expression tree can be compiled to a delegate so the Compile method acts as something very similar to a LINQ provider.
Also note that in practice "LINQ Provider" is often used to indicate simply an implementation of the LINQ API. It is kind of similar to how "argument" and "parameter" are used interchangeably despite the small difference.
Related
I have started to learn Linq recently, So I came across IQueryable and IEnumerable. I have understood the difference and where to use what. But I have a small doubt will IEnumerable and IQueryable have the same effect across all the databases let's say we have PostgreSQL and MongoDB will it have same effect on PostgreSql a relational DB and MongoDb a non-relational database? Could someone please help me with this? Any extra information is appreciated. Thanks in Advance.
The .NET drivers that allow you to use LINQ expressions against SQL and NO-SQL databases have their limitations.
For instance, in mongo's most popular driver for c# website (MongoDB C# Driver), we are recommended to use an analyser to tell us which LINQ expressions are valid or not:
However, and answering your other question, this is only valid for the IQueryable interface, because it is the only one among the two where your LINQ expressions will be translated into Mongo queries. For the IEnumerable interface, you're always safe, as the query will only take place in memory once the data is fetched from the database.
Remember that both IQueryable and IEnumerable support deferred execution. The difference is that with IEnumerable when you instanciate the list (.ToList) you'll be querying the database and ONLY THEN apply your filter (in memory). When you instanciate an IQueryable, it will 'apply' your filter in the database query itself (that's why it is faster and usually recommended when dealing with databases - you'll fetch potentially less data from the DB).
The differences between IQueryable and IEnumerable are very well described here: Returning IEnumerable vs. IQueryable
When using an ORM, and writing queries using LINQ, Who is responsible for transforming the LINQ espression tree to a native SQL? is it the ORM itself, or the CLR? or something else?
As Philippe said in comment - the ORM does it. CLR just compiles your LINQ expression as expression tree, and pass this object to IQueryProvider related to the ORM.
Then this IQueryProvider does parsing of this expression with custom ExpressionVisitor classes. And then based on parsing results - ORM generates pure SQL code, execute it and materialize result.
Some ORM has optimization for this process. For example Entity Framework saves parsed information in memory into something like SQL Execution Plans, and then just uses it in future queries, so it parses it just once, and then reuse data parsed from an expression tree.
If expression tree doesn't have linked parameters, then its easy. Otherwise it needs to partially reparse it again for each execution to get used parameter and generate SQL with them.
it bit confusing, i'm reading these articles regarding linq to sql in mvc but are these links are alternative of each other ? mean one is telling to use LINQ to SQL and other something else ?
Creating Model Classes with LINQ to SQL?
and
Displaying a Table of Database Data?
First one uses Linq to SQL
Second uses Entity Framework. But it's also mentioned:
In this tutorial, we use the Microsoft Entity Framework. However, it is important to understand that you can use a variety of different technologies to interact with a database from an ASP.NET MVC application including LINQ to SQL, NHibernate, or ADO.NET.
So, there're variety of technologies you can use. It's up to you and your needs. That's it.
The second link is using EntityFramework; however, EF is only an ORM. Both examples are using LINQ to SQL.
In the EF example, MoviesDBEntities instance is not accurately represented by its reference name, entities. The object being instantiated is technically called a context (database, in this example). entities.MovieSet is an implementation of IQueryable, which supports LINQ extensions--specifically ToList(), which is the LINQ extension method being used in the EntityFramework example. Calling ToList() will cause the IQueryable instance to execute a corresponding SQL query, returning an object of type List<MovieSet>.
I saw some code were linq was used on a traversing a dictionary object in c#. I thought linq was just for linq to sql for databases. The linq used in the code mentioned was a select type statement, just no database.
Is there linq without linq to sql for databases? Is that "linq" without the "sql" here to stay? I ask that because people talk about the entity framework replacing linq to sql but certainly the EF is not replacing linq that is used the fashion I described is it? Can you use the ef on a dictionary object? Hoping for comments. Thanks.
Heres where I saw it:
How to find duplicate pairs in a Dictionary?
Linq is a .NET framework based technology to query objects (anything that implements IEnumerable). Linq to SQL is an extension to that, that allows you to query SQL Server databases.
Yes, Linq, without the SQL, is here to stay. It is a fabulous technology. One of the best things, IMO, to come out of Redmond, in a long time.
LINQ stands for "Language Integrated Query" and is more than just a way to query SQL databases:
http://msdn.microsoft.com/en-us/library/bb397926.aspx
From the link above:
LINQ introduces standard, easily-learned patterns for querying and updating data, and the technology can be extended to support potentially any kind of data store.
LINQ is used all over the .NET framework now, and, as you mentioned in your question, is available to use against the native generic collection types. For me, this has completely changed how I write code:
List<int> myIntList = new List<int>();
.... populate with some data
myFilteredIntList = myIntList.Where(i => i > 10);
In addition to LINQ to SQL, there is LINQ to Objects, LINQ to XML, and LINQ to ADO.net.
Microsoft has been heavily investing in the LINQ feature set and it is here to stay... that being said, LINQ-to-SQL looks like it will be eventually retired in favor of LINQ to ADO.Net (Also known as Linq to Entities):
http://blogs.msdn.com/b/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
LINQ itself is mostly just a pattern which is supported by language extensions such as query expressions. The implementation working on List<T> etc is usually known as LINQ to Objects; LINQ to SQL and LINQ to EF are implementations for databases via IQueryable<T>. Reactive Extensions provides an implementation over IObservable<T> and IQbservable<T>. Parallel Extensions provides an implementation for parallel processing over ParallelQuery<T>. They're all just working with the pattern supported by the language - methods such as Where and Select with appropriate parameters which can be created from lambda expressions.
Note that LINQ to XML is a bit of an oddity here - it's not a LINQ provider itself; it's just an XML API which works particularly well with LINQ to Objects.
That is sometimes called "LINQ to Objects," but, yes, the LINQ framework itself is here to stay, and the basis of both LINQ-to-SQL and LINQ-to-Entities/Entity Framework.
LINQ works by implementing extension methods on IEnumerable<T> and IQueryable<T>. Everything that implements IEnumerable<T> (i.e. all generic collections [with conversions available for non-generic collections]) can be used as the source for a LINQ query.
In the spirit of
All about LINQ
Current LINQ providers:
LINQ to Objects.
LINQ to SQL.
LINQ to XML.
LINQ to Entities.
LINQ to WMI.
LINQ to LDAP.
LINQ to Internet.
LINQ to Dataset.
LINQ to nHibernate.
So, what is after LINQ?
Does there any data source LINQ not cable of querying it?
[Edit]
From Adam Robinson's answer:
What sort of data source (if any) doesn't lend itself toward a formal query definition?
This isn't after Linq as such, but it's probably after Linq as you currently think about it acting as a pull mechanism on a sequence.
The new .NET 4.0 IObservable<T> and IObserver<T> interfaces (a.k.a. the Rx framework) extend Linq's capabilities to allow a push mechanism and simpler construction of event driven asynchronous workflows. There's plenty more about it if you follow the other posts on the blog I linked to.
So Linq wasn't capable of querying events. But now it is!
You're forgetting LINQ-to-Datasets, et al. However, the question isn't so much about whether or not LINQ is capable of querying a particular data source, since exposing something to LINQ (in a provider-specific way instead of falling back on LINQ-to-objects) just relies on interface implementation. The real question would be what sort of data source (if any) doesn't lend itself toward a formal query definition.
LINQ to WMI
LINQ to LDAP
LINQ to Internet - query the Internet
(from Google)
Linq to nHibernate has also just been completed
You asked:
What sort of data source (if any)
doesn't lend itself toward a formal
query definition?
Linq is a provider so as long as the data source has a way of querying it then it should be possible to create a Linq provider for it. In my mind if you have a data source you also have a "formal query definition" or can create one. If not, is it really a data source or just of blob?