Oct 24th, 2006, 01:54 AM
Domain model without setters
After much more reading I only have more questions.. Lets say I have defined a bunch of Entities in my domain model. To help me create a rich domain model I have removed all setters and getters and for the moment I have a protected constructor. Not a problem for hibernate since it can still access the fields.
(Some setters/getters might come back but this helps me think about the methods of entity a little better)
One of my entities is a User class. It has things like firstnam, lastname, address etc...
So now I need to create a new user and to do so I need to pass the required information into the class one way or the other, here are my alternatives:
1. Put some setters back
2. Use a constructor
3. Create a "VO" and pass that as an argument to a method of User
4. Add various methods to the User class which take "groups" of fields as arguments. For example a method for address(address1, address2, city, zip, country) and one for fullname(firstname, lastnam)
Hmmmm are there other options?
3. might be an option but now I creating more work for myself, do I really need to do this.. 1. might be ok as long as it makes sense.
So I have 1 and 4 to think about, anyone have any thoughts so far?
An additional problem is what if I would like to bind my forms directly to domain entities? Is this a no no?
OK So here again I can create these sort of "proxy" value objects that get bound to the form and are used to populate an Entity class, but do I really need to?
I have read lots of discussions in the forums and in some books but there does not seem to be a simple guideline that attacks the problem from start to finnish... sighhhh
I would be most greatful for any comments.
Oct 24th, 2006, 02:15 AM
I don't think its bad form to have getters and setter on your domain model. As far as I understand, if that is all you have on your domain model, its not much of a model. Adding behaviour to the model allows reuse. There are lots of threads on the forum about your other points though.
Hope that helps.
Oct 24th, 2006, 02:24 AM
Yes, I will keep on reading. It might be about finding a nice balance. Use setters when it makes sense but avoid them if you can... or something like that. I will keep reading.
Oct 24th, 2006, 03:24 AM
One rule of thumb concerning setters: Use constructor arguments for mandatory parameters and setters for optional ones. That way you can also have some sensible validation mechanism on construction.
Oct 24th, 2006, 03:35 AM
Agreed, anything that is immutable should be set in the constructor. Some ORM tools need the getters/setters though unless they can use field access. In this case you would just have to make the method scope as restrictive as possible.
Originally Posted by Andreas Senft
Oct 24th, 2006, 07:11 AM
There are some interesting articles about the whole getter/setter thing. I just typed getters and setters are evil into google. I understand where the author is coming from and his general point but I'm not convinced. Its such a generalization.
Oct 24th, 2006, 07:21 AM
I remember reading the articles before. In my opinion it is here like everywhere: don't go to the extremes.
A model providing only getters and setters without additional functionality might not be the best choice. A model generally lacking getters and setters might be problematic as well. It is important to achieve a healthy balance.
Just my 2 cents,
Oct 24th, 2006, 07:40 AM
A practical suggestion from ground zero .. Please do not get carried away with so much theory. Think in terms of a pragmatic implementation. Design interfaces keeping business use cases in mind and use the UBIQUITOUS LANGUAGE. Hide implementation as much as you can and things will automatically fall in place.
Oct 24th, 2006, 07:44 AM
+1 from me
Originally Posted by Andreas Senft
Oct 25th, 2006, 02:22 AM
This confirms what I have sort of concluded myself...