1. Yes, it is true: code generated object relational mapping is not straightforward.
2. Yes, it is true: for now, scability can only be totally guaranteed by handcrafted coding.
I'm sure the first question was put during the industrialization era, and well put, I must say: for sometime we, like they did back in the 19th century, will not know when to handcraft and when to industrialize. The process is not mature enough.
As to the second question, I believe that we can use the 80-20 rule for many of our projects.
Will we be better served with the tailored version? Hell, yes, but it will cost us a lot more!
Let me give you an example: I'm short and fat, so prait-a-porter is not a good choice for me. But the lucky people that stand near the distribution mean have no problem with the industrialized approach.
My point is: we should weight the earnings that this opportunity can give us against the risk of choosing immature processes, and remember: the industrialization path is sure to be dominant, but we will always have prait-a-porter :)
Just sharing some of my inconsequential lunch conversations with you... 
Friday, October 13, 2006
To ORM or not to ORM
Subscribe to:
Post Comments (Atom)
2 comments:
I have nothing against ORM. But I loathe against code generation. Code generation can save a lote of time, I agree. But it has to be complemented with a great discipline. And that is very difficult to apply.
Who hasn't, pressed by the client, or the project manager, short-circuited the procedures and done something that later regrets?
I can see the advantages, but with real people and real world problems, things happen and code generation is just "copy&paste" on steroids. And that is easily abused.
I tend to prefer approaches that favor encapsulation and modularization (in the back, it maybe doing code generation, or code injection, or whatever). ORM, while not tied to code generation, lends itself to it, maybe not on the code itself, but in configuration of the tables, attributes, ...
Another problem with code generation is the increase in the quantity of code to maintain.
That's why I think, the best solution is to raise the abstraction level (using Aspects and other techniques) or integrate the solution in the language (a la LinQ). To me it's the differente between doing OO in C or Assembly (possible but painful), or incorporate that in the language/platform (C++, Java, C#).
Tanks for your comment, André.
I agree with you is respect to the importance of the contribution of aspects pattern and LINQ integration, but in my view they can be compatible with the use of code generators.
Code generators are nothing but tools to help us produce coherent and repetitive code - humans are too creative and faulty to manage simple tasks like bridging persistance over a database, at least they often have problems to do it always the same way.
Even in the near future, when languages will have built in the object persistance paradigm, I feel that code generators or guidance tools could still be used to leverage and standardise code, or at least to help junior programmers to start working. Even on the next generation, when code is not what programmers see, wizards will take their places.
Maybe the diference between our views can be explained by our experience - my last project was a data form driven web application, with over 500 forms, that couldn't had the contribution of junior programmers without the help of code generators. You probabily have been working on more challenging projects, where code generators whouldn't add value.
Post a Comment