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
Related
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.
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?
I was just reading about Linq to SQL being discontinued. For a while I put off learning Linq at all. Even on asp.net, when I last checked, their data access tutorials were using table adapters and bll classes. Then there are linq tutorials. Now that I have read this and that the Entity Framework is the new way to go, does that mean all the Linq "stuff" I have been reading about for a year and a half, how great it is, etc., is all this just gone? No one ever seems to settle on the right way to do things or at least some standard way with MS products. And I understand that you can't say one way is right for everything. But, in this particular case I do not understand why there cannot be some settling on data access.
Or, is Linq To SQL just the ORM portion of Linq? What exactly would I learn now if I wanted to use an ORM? I have read several things on StackOverflow, but none that really help me know what to do.
It seems that nHibernate may be better than any of the Microsoft choices. Yes, I know there are others (subsonic, and others were mentioned in various SO questions.)
Thank you.
No.
LINQ to SQL is built on top of LINQ, which is one of the fundamental added language features in .NET 3.5 Framework.
Technically other ORMs can implement their own LINQ systems, e.g., NHibernate already has LINQ to NHibernate going. This is on top of the ones provided in the framework, such as LINQ to XML, LINQ to Objects etc.
The Entity Framework certainly doesn't mean that LINQ is going away - the Entity Framework is a LINQ provider itself!
LINQ is a whole collection of technologies, and more than that - it's a pattern which you can implement for your own data provider as well.
LINQ to SQL is just one example of that pattern. For what it's worth, I think LINQ to SQL is being de-emphasized rather than actually going away, but we'll see...
Personally I find LINQ to Objects the most useful LINQ provider in the first place :)
Linq to sql is just one of many linq providers out there (there is linq to db4o, linq to starcounter, linq to objects, linq to ado and many, many more). The entity framework has its own linq provider, called linq to enteties. Your year of reading about linq is not lost.
Linq is much more than Linq-to-SQL. Things like Linq-to-Objects and Linq-to-XML are part of the technology, for example.
I doubt they are going away! Fingers crossed. ;-)
LINQ hasn't gone away. LINQ to SQL hasn't either, but it is not Microsoft's strategic platform for data access, that would be Entity Framework. EF uses LINQ to Entities so if you've spent time learning about LINQ, it'll still be valid and useful.
LINQ isn't a product-specific technology, though. It is easy to leverage the power and flexibility in collections of (almost) all kinds. eg.
List<MyType> myList = new List<MyType>();
// populate the list here
var filteredResults = from o in myList
where o.property == "hello world"
select o;
is (conceptualy) valid, even if the code example here is flawed.
LINQ is a library for processing sequences of data. And it is pretty awesome.
These sequences of data may be anything that implements IEnumerable, or it may be whatever sequences are provided by adapters.
Linq to SQL is an adapter which allows a SQL database to provide sequences of data that are compatible with LINQ.
There is also a Linq to XML which is an adapter that lets you treat an XML document as a sequence of data, allowing LINQ to process it.
LINQ is just the query language, and it is extremely good at what it does. It has nothing to do with databases or SQL. It is definitely worth learning just to be able to process in-memory collections easily.