The Microsoft LINQ (Language-INtegrated Query) Project.
It provides convenient "set based" (really IEnumerable based) ExtensionMethods, integrated into the language.
DLinq an ObjectRelationalMapping layer for all languages in the .Net CLR (CommonLanguageRuntime). Provides closer integration between host and SQL languages than EmbeddedSql, with LINQ's "set based" ExtensionMethods.
Article: "Comparing LINQ and Its Contemporaries", by Ted Neward -- http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/linqcomparisons.asp
Announced at the Microsoft ProfessionalDevelopersConference (PDC) 2005:
Articles:
On embedding XML in a host language:
Note: this is not an ObjectRelationalMapping layer. It is just what it says: queries over various data sources specified in a notation that is integrated into the language (VB).
Perhaps DLink is an ObjectRelationalMapping layer:
DLinq enables mapping of classes to tables, like this:
[Table(Name="People")] public class Person { [Column(DbType?="nvarchar(32) not null", Id=true)] public string Name; [Column] public int Age; [Column] public bool CanCode?; }DLinq specifically enables querying of relational tables using C#/VB.NET syntax, and classes. It also persists instance attribute changes back to the database, with SQL INSERT, UPDATE and DELETE commands.
That does look more like an ORM tool, but I would hesitate to call it a "layer" because the domain model is polluted with details of the persistence mechanism -- they are both intertwingled instead of being separated into separate layers.
I think that the approach of LINQ is not to be an ObjectRelationalMapper, but an ObjectRelationalMixer.
Finally, ideas pioneered by the likes of ExBase are starting to come back in style. Too bad it is munged into a big confusing pile of paradigm potpourri. (See bottom part of ExBaseRant for more my LINQ views, not the part that calls me an outdated stupid loser. Past that.) --top
MS LINQ has inspired a small open source library in Java: LanguageIntegratedQueryForJava
In .net, Linq seems to be a way of enforcing TightFieldCoupling. It works fine if you do not mind tight coupling for the members of a class. If you want to manage the coupling to gain the advantages of LooseCoupling of fields then Linq prevents this. Then Microsoft builds ASP.NET MVC on top of Linq, and you can not do InformationOrientedSoftwareDevelopment? using MVC, and then most ASP.NET employers want MVC, ouch. -- JonGrover
See also: PerniciousIngrownSql (merit debate)