LINQ to Foo
Soma just announced some additional re-branding of some of the LINQ stack. In addition to LINQ to SQL and LINQ to Entities, which were announced at Tech Ed, the ADO.Net stack will include LINQ to DataSet. Additionally, standard LINQ is being branded as LINQ to Objects, and XLINQ will now be LINQ to XML. (There goes XLinq.net I suppose)
Personally, I have no problems with the proposed change and think it makes perfect extensible sense. I previously wrote where this naming would be ideal and see it as a natural extension to the proposed provider model in the future where we might have the following heirarchy:
- LINQ to ADO.NET, which includes:
- LINQ to DataSet
- LINQ to Entities
- LINQ to SQL (formerly DLinq)
- LINQ to Oracle
- LINQ to OLAP
- LINQ to Access (supposedly they already have this internally, presumably testing the provider model with it)
- LINQ to nHibernate
- LINQ support for other data types include:
- LINQ to XML (formerly XLinq)
- LINQ to Objects
- LINQ to Exchange
- LINQ to WMI
- LINQ to ADSI
- LINQ to Amazon
The great thing about the LINQ project is the goal that querying the data will be done through a standardized syntax regardless of implementation. Thus, the only people who would need to worry about the differences would be those that want to provide another provider stack. That stack would just plug in based on a narrowing convention depending on the implementation's inheritance/implementation heirarchy. Currently IEnumerable is handled by LINQ to Objects. If it implements IQueryable, LINQ to SQL takes over. This is not something specific to LINQ, but rather to OO and narrowing conventions on types.
The end goal has not yet been achieved, as can be seen in query syntatic differences apparent in LINQ to XML (ie. requiring the <>@ tokens for element separators). If we can converge on a standardized querying mechanism, LINQ truely will be the unifying way of working with data in the future.