I HATE linq, edm and microsofts bullpatty datastruct
Moderator: Moderators
I HATE linq, edm and microsofts bullpatty datastruct
I just wanted to say that.
.... God Smoth, you should see my twitter feed. For a period of months it was nothign but raeg comments about EDM.
ESQL, to me, is an admission that the whole "compile LINQ into SQL" thing was a leaky, nasty mess. I was actually using EDM 3.5, which really should've been called "EDM leaked pre-alpha pseudo-release".
Meanwhile, at work we use the wonderfully deprecated Linq2SQL which has wonderful failures like being unable to write a "union all" SQL statement without nightmarish workarounds.
The only good thing to come out of linq were the peripheral language features in 3.5 added to support it like type inference, lambdas, anonymous types, and the various ienumerable functional-programming extensions for writing FP-style queries.
ESQL, to me, is an admission that the whole "compile LINQ into SQL" thing was a leaky, nasty mess. I was actually using EDM 3.5, which really should've been called "EDM leaked pre-alpha pseudo-release".
Meanwhile, at work we use the wonderfully deprecated Linq2SQL which has wonderful failures like being unable to write a "union all" SQL statement without nightmarish workarounds.
The only good thing to come out of linq were the peripheral language features in 3.5 added to support it like type inference, lambdas, anonymous types, and the various ienumerable functional-programming extensions for writing FP-style queries.
Re: I HATE linq, edm and microsofts bullpatty datastruct
So what's getting your goat right now? Failures in updating the entity model? Confusing complaints when you try to update an object back to the database? Super-long dynamic compiles resulting in simple queries with lots of pre-fetching taking 6 minutes? SQL translation failures? Linguistic challenges of "I know how to do this in SQL, how the hell do I do it using LINQ?"
The approach I tried to take with EDM was to bolt the logic right onto all the classes. The EDM classes are all partial, so you can add custom properties and methods to them. The problem with that is it meant I was using all the EDM objects *directly*, pulling down a graph of objects from the database instead of a simple list of rows. This is great for having a single unified model in both client and database... but it meant a *lot* of joins, or a *lot* of lazy loads, either one the Entity framework would crap its pants at. There's no way to say "load these related entities and all their related entities along relationships X, Y, and Z" when you have an existing graph of objects and you want to expand it with more stuff from the DB. You can only either fetch X relationships from the database when getting fresh objects, or fetch them one relationship at-a-time.
Near as I can tell, the intended use of these things is to use it *just like SQL*, but with more pain. Trying to use it to code OO database stuff is just agony.
The approach I tried to take with EDM was to bolt the logic right onto all the classes. The EDM classes are all partial, so you can add custom properties and methods to them. The problem with that is it meant I was using all the EDM objects *directly*, pulling down a graph of objects from the database instead of a simple list of rows. This is great for having a single unified model in both client and database... but it meant a *lot* of joins, or a *lot* of lazy loads, either one the Entity framework would crap its pants at. There's no way to say "load these related entities and all their related entities along relationships X, Y, and Z" when you have an existing graph of objects and you want to expand it with more stuff from the DB. You can only either fetch X relationships from the database when getting fresh objects, or fetch them one relationship at-a-time.
Near as I can tell, the intended use of these things is to use it *just like SQL*, but with more pain. Trying to use it to code OO database stuff is just agony.