I have an Entity/JSF Managed Bean Ticket that represents a helpdesk
ticket.
It has a status property; when the status is set to closed I want to
change the value of the closingDate property to the current system time.
But I think that code should be contained in the bean, as each time the
ticket is closed the time should be recorded.
What would be the proper way to manage it? I have several ideas.
- Make setter of
creationTimeprivate, and change its value when the
statussetter is called. Fast and quick, but makes a setter change two
attributes. Also, forces me to use JPA field access (not much of a problem
as I am already using it, but still a limitation) and I am not clear of
what will happen when the bean is serialized. - Make the
statusproperty a bound property as described in JavaBeans,
and make the class aPropertyChangeListenerto itself. Very formal, but
a little overcomplicated to my likening. - Make setters for both properties private, and add a non-bean method
close()that performs both actions. I would go this way but it can make
me it complicated to work with JSF. - Do nothing. Keep the bean as dumb as it can and move the logic to the
controller; cross my fingers hoping that nobody forgets to update both
attributes.
I favour 1) or 3), but I would like to know if there is a better approach.
I don’t know if anyone can tell you the proper way to manage it, as arguments can be made for many different approaches just like you make them. To add to your list as a combination of 1) and 3), for example:
statusupdatecreationTimewhen itstatusis set to closed and leave both setters public. Has benefits from both as I’m not aware of any downside to this from a JPA perspective.What I would advice against however is having a Entity/JSF Managed Bean. I would recommend having two, an Entity bean and a JSF Managed Bean. This way your Entity bean can be kept as dumb as it can be, while your JSF Managed Bean will have smart methods like
close()orreopen()and comprised of a series of dumb calls to the Entity bean. Also, you can do things likepersist()in@PreDestroy. Easy to develop, easy to maintain, easy to make decisions. Hopefully you’ll find this helpful.