I have a game consisting of a client / server + a webpage. A central notion in both client and game-/webserver is an Account. Accounts are stored in a database thus I’m in need of some ORM and recently had a look at Hibernate and Cayenne.
My understanding however, is that both frameworks provide an "DatabaseBackedAccount"-class which I extend with my other Account methods. My problem is that the Account class is reused heavily on the client side, and I would obviously not want to include database-related code on the client implementation.
My current solution is to have an Account class (shared by server and client) and extend this with a DatabaseBackedAccount (overriding setter-methods and providing a commit method) on the server side. I find this quite natural and nice, however I’ve had to implement all gory sql-details and ORM myself.
Is there any way to “turn the table” in any existing ORM framework, so that the generated classes extend my existing class?
In JPA (and in hibernate, but I know JPA better), there is no magic inside the entity classes, they are just POJOs with annotations (or configured via xml). So you may use them happily on the client side without any implications on the server side, as all the magic happens from the outside through the EntityManager interface.
And on a more general note: an account should not be allowed to commit itself (just as it should not be allowed to create or delete itself) , there should be a service or DAO that does that from the outside, thus creating nice and clean POJOs that you can use on both client and server side.