LINQ is a query language built into C#. For C# 3.0 Microsoft has added a large number of keywords into the language that allow a developer to query into objects in a SQL fashion. This can also be used to select from a database when the Object being queried is a DB mapping object. Like Hibernate, they have an ORM mapping from a database to a class and a session (called DataContext) that is used as the glue. Nicely, for the RAD folks this can all be auto-generated or done by hand for those who don’t like generation. Very rails like in concept when considering the generation, the database is defined and then the code created by a tool. Rails does this at runtime, but the concept of database creation first and by hand is the same.
Unlike Java and rails, you don’t need to use the full blow Objects for result from LINQ. Instead you can create structs on the fly that contain only the fields you have selected. You can unit test this by mocking out the struct by hand. Although interesting, I’d think that this would only be useful in select cases considering that design by contract makes most sense on the domain of the application rather than an anonymous class created by the language at runtime. For distinct DB code snippets where performance is necessary and the data is confined, these structs will be ideal.
In terms of performance, Microsoft stated that LINQ does not cache at all and leaves this to be done outside of LINQ. Cache, distribution and the like are difficult and it does seem like they have punted on this instead of addressing it. Considering that hibernate and most other tools provide this and will handle distribution if the correct caching provider is supplied as well as handle no caching with simple configuration makes me think that LINQ just didn’t have time or didn’t want to try.
LINQ handles transactions as expected. Programmatic transaction can be done via the DataContext. If you have a distributed transaction then LINQ will participate in that transaction. If the backend doesn’t support transactions then it is not supported by LINQ because internally it goes directly to the data source during any execution statement.
My main concern with LINQ is that they have add to the keyword namespace of the language and reduce the user namespace, which will no doubt make old code break everywhere or reduce the chance for upgrades. This doesn’t bother me too much I guess when considering that this release is a major release (3.0) and Java suffers from the inability to add keywords that would make life easier for developers simply because they refuse to break old code. Still, the reasoning behing using keywords is not clear and Microsoft did not provide a distinct reason they used keywords rather than a block. The also had no idea off hand how many keywords LINQ uses up. They tried to use the blocks are ugly argument, which is not true considering that ruby does this nicely with 3 distinct characters and 4 total characters.
