On LINQ Hesitation

I hear this post on the potential scariness of language integrated query:

On the other hand, I’m still not sure I see the practical side of things. I cringe when I think of all the query logic that is going to be embedded in code. Actually, from this perspective my real problem is with DLINQ, not the LINQ syntax itself. That is, I really have no problem with a syntactic nicety on in-memory objects, I’m just a little more concerned when your code is so tied to an external data source. - Tim @ slashstar.com

It’s important to remember that entities are a ’safer thing’ (than straight-up relational constructs) to type into your code. Straight up, that’s just not something we’re used to. The mapping layer is there to reduce coupling between DB and Code.

Remember: in a domain model, it’s perfectly legit to have QueryObjects all over the joint. Usually those will involve some “magic” strings (bad, bad, bad). I’d certainly rather have the query in there typed to get the free compiler checking after a DB refactoring is attempted.

I think there will always be scenarios where you’ll want to assemble queries at runtime with Metadata. I guess you’ll have to options: use reflection to emit an assembly at runtime (wow, overkill, but might have cool uses) or use the metadata service (mentioned in the ADO.NET VNext vision statement) to formulate ESQL to do some interesting things.

Post a Comment

*Required
*Required (Never published)