Suppose we have some classes in our application domain. But we don't want them to be "tied" to a particular persistence framework. These classes should just express the particulars of the domain concepts....no ID's, no mappings, no annotations; To implement persistence on this domain, how about deriving these classes, and applying hibernate (for example, or any other ORM) mapping files (or annotations) on the DERIVED classes ? Is this possible ? Can you apply mappings on inherited fields ?

10x

Hibernate version: 3.1.3

Mapping documents: irrelevant

Code between sessionFactory.openSession() and session.close():

Full stack trace of any exception that occurs: irrelevant

Name and version of the database you are using: MySQL 5.0

The generated SQL (show_sql=true): irrelevant

Debug level Hibernate log excerpt: irrelevant

inheriting fields is no problem, of couse. so you can do that.
but anyway, if you use Pojo's you are already independent of the persistence framework. That's the idea about Pojo's.

Not exactly: consider a class in a domain, let's say "Customer"; Hibernate doesn't require (except for reataching detached objects), but strongly recommends defining an ID field, like "CustomerID". Now comes the fun part: this "ID" field is only relevant to Hibernate or (probably, but not certainly) to some other ORM; when you want just to describe your business model you talk in terms of classes and their relations...you don't have to think about database details....not even a simple "ID" ;-)

I want to move these details in a "hibernate specific domain class" which of course uses through inheritance the "pure" domain class.

10x

I've done something similar, where I have an abstract class that takes care of property definition/getters/setters, and a concrete class that takes care any other business logic. So you can definitely map and use properties from an inherited class.

All you should have to do is create your "hibernate specific domain class" that extends your base class, include the ID and any other hibernate specific properties in the new class (I can't think of any besides ID, but maybe there's something else you'd need), and have your hibernate mapping file point to the new class. As long as all properties in all classes that are mapped have standard getters and setters you should be fine.

You could then have a service layer or something that knows about hibernate and asks it for the hibernate specific domain class, but the return type is the more generic class, and the rest of your code doesn't have to even know that the hibernate specific class exists.

10x; it seems a good pattern