Should an O/R mapper be a code generator?
Here is a post by Tobin Harris that tries to answer whatever an O/R Mapper should be a code generator (interesting discussion in the comments of both the second posts).
[Update: I just noticed that the second (original) post is from 2003! ]
What caught my eyes is this quote:
NHibernate is certainly well suited to legacy projects where I'm not in a position to change the database tables, and the more tricky situations where you might have things like composite keys, different identity schemes, and value type mappings. It can take time (and therefore money) to to learn to use these features, but if you're project needs such flexibility then it's there for you. NHibernate was built to solve certain kind of problems very well.
In my opinion, this is gross mis-characterization of NHibernate, while it can works with all the legacy' warts, it doesn't have to, and in fact, it's very good tool to start working on a new project*. If you ignore all the legacy support, it's a very clean model. A class needs to define a mapping that contains an identifier (Primary Key), and any number of properties / objects (Foreign Keys). The resulting code is very clean and easy to work with.
*I'm not a partial observor, of course, I've invested quite a lot in NQA.
Comments
Comment preview