Data frameworks: What problems are being solved?

I openly admit that perhaps I'm not the best blogger when it comes to technology, because I have a very skeptical "why should I care about this" attitude toward everything new. And specifically for programming, because I'm not very computer science oriented.

So when it comes to the various data frameworks of the .NET world, the ORM's, LINQ to SQL and the entity framework, I often find myself asking why I need to care about any of them. With the recent debates about the alleged death of LINQ to SQL and flaws in the EF, I only scratch my head more. The reason for my apathy toward these subjects is that I tend to rely on the "smarter" portions of the community to solve problems for me so I can get to the business of building stuff.

I think the people that I look up to for answers and guidance often get disconnected from the problems that are out there. Frameworks of all kinds often grow into these giant things that do too much and obscure the original problem (see Vista for the biggest case study of all ;)). Or perhaps there is some amount of mismatched expectations when these tools are developed.

For example, the thing that I really want out of any of these data frameworks is less code to do simple things. If I want to insert a row into a table, I want to do it in as little code as possible. Having some kind of object representation is nice, I suppose, but only in certain circumstances (some small line-of-business app: good, some component of enormous system with its own entities: bad). LINQ to SQL does a pretty decent job in this role, but sometimes it makes me do things I don't want to (like create primary keys where they aren't necessary), in the name of a feature I don't care about in that instance like concurrency checking. Then when I look into it more, I start to wonder if I'm really gaining efficiency anyway, since my "few lines of code" can't work without a ton of generated code, or code that I write.

At the end of the day, I find myself going back to little code libraries I've used previously, or even pieces of the old enterprise application block or whatever it was called. It's pretty hard to beat a method that takes a stored procedure name and an array of parameters!

Between my current unemployed state, the holiday and a much needed vacation, I've been away from code for about three weeks. While liberating, the thing I find as I re-engage is a clearer thought process on the things I need to get things done. My fear is that the .NET community, both at the Joe Blogger end and from within Building 42, has somewhat of a disconnect from the development world at large. I'm not suggesting that this won't correct itself with time, but the whole "we're blowing off LINQ to SQL even though people are getting heavily invested in it" thing concerns me. I don't need drag-and-drop dummy tools, but I sure would enjoy some of the super clean and direct goodness we're seeing in the Javascript framework world applied to .NET's data realm.

4 Comments

  • Mirrors my thoughts exactly Jeff!

    im currently hedging my bets on subsonic 3 to provide the flexible lightweight, code-less solution for data access that we all seem to want.

    fingers crossed...

  • Totally agree. There's a huge disconnect between what Microsoft thinks we want and what we really want or need. The main problem, in my opinion, is that the team / people who build these frameworks either never really get to use their stuff or that they're incapable of putting themselves in our shoes.

    If they would be forced to write 1000 times the 5 lines of code that reads a record from the database, I bet they would do their best to make that operation as smooth as possible -- maybe only one call. Since they don't use the stuff they build like we do, they'll never understand "our side." I personally can't imagine someone from the LINQ to SQL team actually using the designer for a large project and not realizing within 15 minutes that there should be a way to refresh the diagram without re-adding the tables. I won't even go into how slow it is.

    To be clear, I'm not painting everything that comes out of MS with the same brush, but there are a number of things that MS produces that, even though in smaller numbers, taints the good stuff they make.

    After a few bad experiences like this you get numb to new stuff coming out because in the back of your mind you keep thinking "What did they leave out this time, what shortcoming will I have to live with? I better wait a while until they either dump the thing or it went through enough cycles that it may actually be usable..."

  • i also agree but iwould like to add similar to what i wrote on Andres Heljberg forum on Linq. That the Learning curve to do the same thing is oppressive since "we" over time build and learn our "own" frameworks in the form of helper classes/routines !

    Then these Microsoft Noobs! build new "Utopian" data-access models to justify their jobs/Ego and time in Microsoft Research !

    Innovation in the right areas in useful and justified, such as in the speed, IDE improvements etc. but it also has to weighed against what is already invested in .... I have written libraries, tinkering with it over 5 years which is based on the same fundemental pprinciples of 7 years ago ! easy to learn, easy to pass on the Knowledge ! easy to maintain (since everyone knows the fundemental principles) ! easy to develop ! easy easy easy !!

  • I really don't think it's about anyone's ego, no matter how many exclamation points you use.

Comments have been disabled for this content.