Linq. And DLinq
Linq. And DLinq.
I'm going to go straight to the point. I think Linq is a good thing done the wrong way.
Let me backtrack and explain. Linq's main usage will be to query the "in memory" representation
of a list/array/data structure of business objects. ( Karmencita....our solution for this will be available
next month with DataBlock v1.3) That's it.
The problem with Microsoft is that you don't have business objects. And here is DLinq comes. It
seems that with DLinq they *tried* to create a mini O/RM . (finaly indirectly Microsoft
admited that ADO.NET pretty much blows chuncks for writing data access code).
So they seems to combine a code generator which based on the databse schema generates a mapping class.
Nothing out of the ordinary....we've been doing this (we...as in the O/RM writers) for some time.
But still MS manages to screw it in a couple of ways :
- DLinq generated code is database specific (Sql Server only).
- It seems it's not extensible. So bye bye PostgreSql extensions for instance.
- The mapping information is held in attributes. As a O/RM writter i can tell you that IT WON'T SCALE.
It works with a couple of tables but it will NOT scale for a enterprise application with 30-40 tables.
- only querying. What about CREATE, DELETE, UPDATE ?!
If this is the descendant of ObjectSpaces then (ok....i might be a little mean here) i think every O/RM vendor can relax.
Linq is not a solution to write some serious database independent datababase access code.