Why are people continuing to use xml mapping files instead of annotations? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it 开发者_如何学运维can be answered with facts and citations by editing this post.

Closed 9 years ago.

Improve this question

I've observed the strange fact (based on the questions in the hibernate tag) that people are still actively using xml files instead of annotations to specify their ORM (Hibernate/JPA) mappings.

There are a few cases, where this is necessary:

• you are using classes that are provided, and you want to map them.
• you are writing an API, whose domain classes can be used without a JPA provider, so you don't want to force a JPA/Hibernate dependency.

But these are not common cases, I think.

My assumptions are:

• people are used to xml files and don't feel comfortable / don't want to bother learning to use the annotation approach.
• Java pre-1.5 is forced upon the project and there is nothing to do about it
• people don't know that annotations are a full-featured replacement of xml mapping.
• legacy systems are supported and hence changing the approach is considered risky
• people fear that mixing annotations (meta-information) with their classes is wrong.

Any other possible explanations?

---

The domain layer and the persistence layer are considered by some to be separate concerns. Using the pure XML approach keeps the two layers as loosely coupled as possible; using annotations couples the two layers more tightly as you have persistence-related code embedded in the domain code.

---

• Lack of overview of what's been mapped. You need to dig in the source code.

---

people don't know that annotations are a full-featured replacement of xml mapping.

Ah, but they're not. Three cases off the top of my head (there are probably more) you can't do (well) with annotations:

1. Use formula as part of association key (admittedly, rather esoteric).
2. Join-via-subselect - @Loader is not an adequate replacement. Not too common but quite useful. Envers provides a viable alternate approach.
3. Losing column order for schema generation. This one's an absolute killer. I understand why it's done this way, but it still annoys me to no end.

Don't get me wrong, though - annotations are great; doubly so when they're coupled with Validator (though, again, #3 above kills the buzz on this one). They also provide certain aspects of functionality that XML mappings do not.

---

Using XML to complement the annotations, where environment or system specific configuration is needed.

---

Some information is carried nicely in annotations, such as the cardinality of relationships between entities. These annotations provide more detail about the model itself, rather than how the model relates to something else.

However, bindings, whether to a persistence store or XML or anything else, are extrinsic to the model. They change depending on the context in which the model is used. Including them in the model is as bad as using inline style definitions in HTML. I use external binding (usually—though not necessarily—XML) documents for the same reasons I reference an external CSS.

---

I initially found the annotation syntax very weird. It looks like line noise and mixes in with where I usually put comments. It's vastly better than dealing with the XML files though, because all of the changes are in one place, the model file. Perhaps one limitation of annotation is possible collision with other annotations, but I haven't seen that yet.

I think the real reason that it isn't used more is that it isn't really considered the default. You have to use an additional jar file. It should be part of core and the XML approach should be the optional one.

---

I've switched to annotations, but sometimes I miss the XML mappings, mainly because the documentation was so much more comprehensive, with examples of many scenarios. With annotations, I stick to pretty basic mappings (which is great if you control the data and object model), but I've done some very complex things in the XML that I don't know if I could replicate in the annotations.

---

So if you want to deploy your class to multiple datastores. And you want to annotate column definitions into it do you ? Different datastores have different conventions etc and using XML is the only sane place in that situation, being able to have one for MySQL, and one for Derby, and one for Oracle or whatever. You can still put the basic persistence/relation annotations in if you wish, but the schema-specific stuff would go into XML in that case.

--Andy (DataNucleus)

---

I have a new one : http://www.summerofnhibernate.com/

Very nice screencast series not yet covering annotations. I have written some apps with it to learn the basics, not for my job but out of curiosity, but never migrated to annotations yet. The series where suggested as still relevant on SO. I still will migrate to annotations if I have some more spare time but for the time being I could be one of the persons asking questions about it.

---

I worked on a project where the database would change very frequently and we have to regenerate the java files and configuration files each time it happens. Actually we do not use all the relationships and configurations generated by hibernate tool. So basically we use the tool and then modify/tweak them.

So when you want to modify/tweak the default configurations, it is easier to do in the XML file in comparison to doing it through annotations.

---

I feel that it makes the code much more readable if we donot use Annotations.Use of Annotations can really help if the configuration info changes frequently, but take the case of web.xml, how many times does the info in that change, so why use annotations for Servlets.

---

We continue to use XML because typically for deployed sites, getting a patch (binary code) approved for installation takes time that you may not have. Updates to ASCII files (e.g. xml files) are considered configuration changes and not patches...

t