views:

1158

answers:

11

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?

+3  A: 

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

David Rabinowitz
This is even more true when you are dealing with Dependency Injection configuration. When you have a large application with tons of configuration, using all/pure annotations approach make it hard to get the whole picture of how your application is tied together. In this case, XML configuration is a really good complement where you can have a somewhat *centralized* configuration that give overall picture on how all the puzzle pieces fit together.
DJ
while you are correct, the whole puzzle should be obvious from other things, such as packaging, naming, etc. :)
Bozho
+1  A: 

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.

Peter
+16  A: 

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.

kem
that's a fair point, although I don't think coupling at that point is harmful. Apart from the runtime dependencies, the objects can be used as if they are decoupled from the peresistence meta-data. And the persistence meta-date, well, it cannot be used without the domain objects.
Bozho
+5  A: 

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.

ChssPly76
is losing column order that much of a problem, actually? It sure isn't nice, but I'm currently working with generated tables with 30+ columns and it isn't a big deal.
Bozho
It's a problem if you're using Hibernate to generate your schema - either directly or via liquibase. And by "problem" I don't mean "it doesn't work" - but it's hugely inconvenient to work with (or even look at) resulting database via external tools. Unless you name your properties alphabetically :-) things like primary / foreign keys will be at random (as in "not the same as in source code") places within your table.Maybe it's just me, but that kills me - to a point where I've had to patch annotation binder to preserve property order using some of javassist black magic :-)
ChssPly76
hehe. Yes, I'm using direct schema generation, and it is a minor inconvenience, I think.Btw, have you submitted your patch somewhere?
Bozho
I can't, unfortunately, for legal reasons. Based on past experiences, however, it would likely be not accepted anyway - Hibernate team is very umm... selective :-) anything other than straight up bugs. Besides, javassist is indeed black magic; I have this deployed and working on 3 separate platforms but I've no idea whether it will work consistently on others. If you're interested in this, let me know - I can't provide the actual code but I'll give a few pointers; it's not horribly hard to write once you know where to look.
ChssPly76
In an Oracle database, it's optimal to have null columns at the end of your table. All the null columns at the end take up no space (NB. not "very little space", but no space at all).
WW
+1  A: 

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.

Priyabrata Hota
I think database changes should follow model change, not preceed it.
Bozho
+1  A: 

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)

DataNucleus
A better place to configure naming conventions is the NamingStrategy.
Bozho
Who is talking of naming conventions ? column lengths, column types, etc are also variant across RDBMS types. Many things. JPA has no such NamingStrategy. Clearly if you've already decided that you're using annotations only then just use them, but don't say you weren't warned.
DataNucleus
And I haven't said using xml is wrong. (and the downvote isn't mine ;)). Hibernate has NamingStrategy. And what other conventions? Generally speaking, ORM mappings should be database-agnostic.
Bozho
So if one RDBMS supports BLOB and another doesn't, then ? And in some you need to store Boolean in one way and in another a different way. They don't all support the same JDBC types. Obviously it depends whether datastore portability is an issue for your app being required to be deployable across many envs; for many apps it isn't.
DataNucleus
A: 

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.

Rajat
if there were annotations for the servlet API (they will appear in 3.0), I would be asking the same question for it. In my opinion, reading annotated classes is easier than making a paralel between the class and the mapping.
Bozho
Its mostly a matter of choice i think.To me reading 10 lines of code is better then reading 10 lines of code + 10 or 20 more lines of config info.
Rajat
+2  A: 

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.

MattMcKnight
+1  A: 
erickson
While I agree with this being the most valid point, I, personally, don't think this separation is so necessary. Even if there are contexts, where the annotations need to be changed (RDBMS weirdness, for ex.), the specific problematic places can be overridden with one small mapping file. (One point of using external CSS is reusing the definitions, and here we don't have such an option.)
Bozho
My biggest motivation to use CSS is separation of *roles*. In development, there are some strange loops where the difficulty of binding a particular construct actually influences the model design, but developers quickly internalize some rules of thumb that let them create a model without worrying too much about the binding. After that, it's reasonable to split the jobs of modeling and binding between people or even teams. Another point worth mention: in the case of XML bindings, it's very likely that a single model will be bound to multiple schemas. External bindings enable this.
erickson
+4  A: 
  • Lack of overview of what's been mapped. You need to dig in the source code.
BalusC
+1  A: 

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.

Brian Deterling