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.