Apr 7th, 2008, 12:48 AM
Domain Object Design
I'm deep in my first Spring/Hibernate project and have a question regarding domain object design.
I first designed our datamodel, wrote the hibernate mappings, and then built a businesslogic front to a bunch of DAOs that could persist each domain object. This all works great, and up to this point, Spring handled the DAO/businesslogic DI and Hibernate sorta managed the domain model/persistence side of things.
Enter the web layer. Today it took me quite a while to figure out why I couldn't add a new object to my database using a SimpleFormController: Spring thinks every one of my data objects is a simple JavaBean (they are), but it also assumes all getters and setters are public (they aren't).
I was trying to avoid two things in my design:
1. Anemic Domain Model: If I wanted complex logic in my code (aka children adding themselves to parents' collections, certain validation strict enough to belong in the model itself, etc.), I'd make a public setter for human use when creating detached domain objects, and a private setter which is stupid and just sets the property.
2. Mutable objects: If I wanted certain properties to be immutable, I'd make the setters private and only allow the properties to be set through a public constructor... Hibernate could of course use a package constructor and the private setters.
My problem with Spring MVC is that it can't use the private setters for my objects, so it seems that I should make them public, breaking the immutability of the fields.
SO: What's the best design? Completely stupid objects with no logic at all? Just a bunch of getters and setters? This seems incredibly moronic.
Should I ditch all my complicated logic (for use by humans) and just make all the stupid getters/setters (currently for use by Hibernate) public?
Help is appreciated!
Paralyzed by Design