Hi all,

I've been using NHibernate for a about 3 to 4 months now, and am absolutely positive that it's the persistence layer to use (at least, for me (and my company)).

One thing still keeps nagging though: Should I use attributes or just plain xml to map the domain?

Personally, I've developed a preference for mapping with attributes and used the generated xml as a second source of information to find out why a mapping didn't work (i.e.: what I did wrong).

Attributes introduce the notion of persistence to the domainlibrary.
On the upside, I think it makes developers aware of persistence and reminds them that it's not magic at work but a persistencelayer, and simultaneously (hopefully) alerts them to pay attention to *what* they change and the consequences it may have. On the down side, well, it introduces persistenceinformation in the domainlibrary ;)

I'm happy (and curious) to hear about everyone's opinion on this issue.

At the moment I use NHibernate for the pet project only.
I have chosen to use Attributes also. My main reason was, that I did not want to maintain two versions of class structure (mapping and code files). Also, it makes typos less frequent.

The only (propable) difference is that I did write my own hbm writer, and my own set of attributes. Reason: I want the hbm to be generated in quite restricted way (I would propably never use comnposite id, for example), so I can leave out many details from attributes - they are defined implicitly.

Just my .02$

Gert

I see NHibernate attributes more like documentation; they do not affect the behavior of the entities; so I also prefer this way.



This is interesting. Can you give more details about that?
Do you see some places where NHibernate.Mapping.Attributes can be improved to better support your "restricted way"?

That is another benefit indeed. One source that rules all, if you will :)



I've thought about writing one from scratch (accompanying attributes included), but voted against it for the moment. Partly because we've got legacy databases that do use such features, but, to be honest, mostly because I simply lack the time ;)

Indeed. I think it translates my thoughts better than my own rambling in the original post. Developers can focus on classdesign and implementation, while still keeping an eye on the infrastructure already there.

Well, for example, I have decided that by default, all proeprties of persistent class are stored. If I want a property to be non-stored, I add attribute for that.
Also, all my classes use same equally named ObjectId and version properties, so I do not need define those with attributes.
Third, I always use nosetter.pascalcase-m-underscore as access modifier, so it is hardcoded into hbm writer.
And lazy loading.

Also, I have decided quite certain way to define collections, so my typical IList looks like



So, most of the "improvements" are depending on my coding style, and not usable for general audience. But they help me to keep code files a bit cleaner..



I haven't analyzed what and how the NHibernate.Mapping.Attributes provides. I looked at them briefly when I started using NHibernate (version 0.9.x I think), but decided that they required too much details that were constant in my implementation.

Gert