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?
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
Is LINQ an ORM ?
I've heard a lot of people say LINQ follows the rules of an Object Relation Mapper. But I don't understand; is this true?
LINQ is a C#/VB.NET language syntax and a set of method signatures for querying data.
There are many providers for this syntax and some of them are ORMs. The simplest case is when you are querying collections in memory which is not an ORM. There are also ways to query XML, Active Directory and many others which are not ORMs using the same syntax and the same set of methods (implemented differently).
Practically every serious .NET ORM technology has some level of LINQ support
LINQ to SQL is the first ORM to support LINQ and it was kind of a proof of concept. It is easy to learn and lightweight but lacks a lot of features. It is still pretty decent and Stack Overflow used it (I'm not sure if they still use it).
Entity Framework has LINQ to Entities provider and it is the heavy hitter from Microsoft.
NHibernate has a LINQ provider that in my opinion barely works but they may fix it some day
There are more ORMs out there and most of them have some level of LINQ support.
Ok people, repeat after me:
LINQ is NOT about working with databases.
LINQ is an abstraction layer for working with data which allows for set based operations, projections, filters, etc on anything that can be enumerated over. It just happens to have providers for working with relational data (LINQ to SQL, LINQ to Datasets, LINQ to Entities).
Is the LINQ ORM ?
No. Linq is not itself an ORM.
This code uses Linq to Objects, which is still valid Linq:
var someData = new int[] { 5, 3, 2, 7, 4 };
var someResults = someData
.OrderByDescending(i => i)
.Take(3)
;
And here is some Linq to XML code:
IEnumerable<XElement> partNos =
from item in purchaseOrder.Descendants("Item")
where (int) item.Element("Quantity") *
(decimal) item.Element("USPrice") > 100
orderby (string)item.Element("PartNumber")
select item;
Neither of these code samples have anything to do with Object Relational Mapping, since they don't map objects, nor do they work with relational databases.
Linq has been used with some ORM technologies though:
Linq to Entities allows you to access the Entity Framework ORM with Linq.
Linq to NHibernate does the same for NHibernate.
You can find out how Linq itself works by checking out this library and the associated articles. They deal with Linq to Objects, but will give you the basis of how Linq itself works:
http://code.google.com/p/edulinq/
It will show you that Linq need not have anything to do with an ORM.
If we were to go by the wiki defiinition of the term Object-Relational Mapping,
Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.
http://en.wikipedia.org/wiki/Object-relational_mapping
then yes, LINQ is an ORM in the sense that it is a programming technique for converting(and querying) data between incompatible systems in object-oriented programming languages, creating, in effect, a "virtual object database" that can be used from within the programming language.
LINQ is Language Intergrated Query and is NOT an ORM.
It can be used as query layer on top of an ORM product like Entity Framework or Telerik Open Access or NHibernate.
ORM is as you say Object Relation Mapper - it does mapping between entities in the database layer to entities into your Object Oriented code - classes that represent the database in your application.
For further discussion see this question.
Just wanted to know if NHibernate 3 have full linq support yet ?
Thanks.
There is no such thing as "full" LINQ support.
LINQ to anything except Objects is a leaky abstraction. Some operations that are trivial to express in an object model are hard to translate to SQL, and vice-versa.
That said, the LINQ provider in NH3 is quite usable, and a lot of work is being put into it (a lot of that will be visible in the 3.0.1 release, which will be out around 28/Feb/2011)
The good news is with NH you always have alternatives. If you can't do a particular query with LINQ, there's always HQL, Criteria, QueryOver and even SQL. They all integrate nicely with the rest of the stack.
No there are still some unsupported features. It's not a full LINQ implementation.
It doesn't have full linq support because it is too much (impossible much) work to write a full link provider. I don't think any full linq provider exists.
You can find the currently unsupported features in Jira.
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.
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.