> I agree with John, and will like to add that I don't see the point of a
tool
> generating code for another tool that generates code.
> Is like if the FNH team choose to generate LLLBlGen Pro dsl.
> I hope this will be taken as a constructive comment.
You mean, generate FluentNH code from a model? Maintainability. The
model is easy to refactor, search, examine, extend, change. If you think
your classes are the model, you don't understand what o/r mapping is all
about. The classes are projections of entity definitions, not the SOURCE of
the entity definitions nor the entity definition themselves. So when you
_change_ the model (in whatever way), that change may cause changes in the
projections of the model in various forms. Like changing a 1:n relationship
into a 1:1 relationship. That single change has more than 1 consequence for
the projections of it (class + table + mappings). That's why generating
classes + mappings + tables is beneficial: you otherwise have to make these
changes manually, maybe forget one, or do it poorly. But hey, if you like to
mess with XML all day, go ahead, it's your headache ;)
When someone decides to continue a project without the model, s/he
can: all mappings are in readable fluentNH code, you can continue right
away.
that fluentNH generates xml behind the scenes is really a problem of
NHibernate, not of fluentNH. I didn't even know that at first, to be honest,
I only realised it when I had a strange issue and it barfed on an xml error,
but I didn't write xml.
> XML in his both representations as raw XML or as HBM* classes is the
lowest
> common denominator.
> See? I read Fabio's blog.
good for you.
FB
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/nhusers?hl=en.
