ORM , mastering complexity for the “real” challenges yet to come
Andres has an ongoing discussion taking place right here. I think we should not hide this discussion in comments, but throw the ball up in the blog-air, who's catching?
Did anyone here worked on an application with a shitload of associations between entities? Ever thought about loosely coupling? Ever done some serious maintenance on .NET applications build upon DataSets or Typed DataSets even or tried to extend an application? My personal experience is that applications build with ADO.NET objects as carriers for entity data are a hell to maintain or to extends. You as a programmer should always be aware of the “relational structure” of your app. Basically you’re just adding some bits and peaces of logic on top of your data model. I personally prefer solving business problems in a somewhat more intuitive way.
Exactly this is the point of no return, the brick bashing Fowlers window… the breakpoint for you to drop Microsoft pr-garbage and drop this nasty methodology. Scalable, reliable, extendable applications are mend to solve business problems by transforming the complex problem is an easy to understand and use model. This model certainly doesn’t have to be a 1:1 image of the business or one size fits all solution, but should be able to get the job done! What the hell are we doing here? We are discussing technical solutions not by acknowledging the tradeoffs in favor of solving our business problem, but comparing .NET technology. I feel like we as a community are lacking from this point on.
To sum it up, it all depends on “what to solve”. I’ve noticed a solid OO-model gives me a hell of a lot information to solve my business problems in contrast to ADO.NET objects where I get the sense that I’m still bashing Recordsets like structures (in fact I am) and constantly working with a print-out of my the data model on my desk. Little changes in an OO-model simply mean adding attributes, hooking extra associations (this is not as simple as it seems) and modifying my mapper (home made framework ;)). In contrast, ADO.NET objects force me to “yet again” make a new print-out of my data model and discuss the “what would and what could happen” if we change here, here and here with my team. Does this break our application?
To bad 95% of the managers making the vital decisions read Microsoft’s pr and instruct me to use ADO.NET objects no matter what, across tiers to solve uttermost complex business problems, which provides me with a lot of work and maintaining crappy applications ;) Make the right decisions, but be aware of changing requirements! I prefer OO anytime because that way I can earn my boss money (reading this? Yes I like you to make cash, $) by participating evolving requirements fast, effectively and deliver quality software that fits our customers needs. Why? Because I’m a self trained software engineering and not to shy to make mistakes and refactor any day any time.