I'm currently working on a Domain Object model. To me the idea of putting a BigInteger in the object for database tracking is wrong. The domain object should not know about its persistence mechanism. I thought about making the actual domain objects all abstract. The database objects would all extend the domain objects. In actually the code would use the implementation versions at runtime, but the model is programmed to the interfaces.
However, I've never seen this done. Is it a good idea?
>>To me the idea of putting a BigInteger in the object for database tracking is wrong.
Why? Let's hear your reasoning. Indeed, Java objects can be uniquely identified without an id, but we do need to bend a little to address the reality of a database. Is this too much bending?
>>The domain object should not know about its persistence mechanism.
Having an id doesn't map an object to a particular database or persistence mechanism. If anything, it simply recognizes the fact that the data will, at some point, be persisted.
I thought about making the actual domain objects all abstract.
It's a beautiful design. Abstraction is elegance when it comes to Java design. But the purpose of abstraction is flexibility and plug-ability. Is this your goal? I'm not so sure if it is, or for that matter, if it will ultimately help you achieve your goal.
There is a balance between elegant design and simplicity. Sometimes simple is good. I hate seeing reams of code with all these BaseClass, BaseClassImpl classes. It just looks so doggone ugly, and it's needless. Don't add needless complexity to a simple design problem.