I initially tried to use my domain POJO's as the command (form backing) objects in my web layer but quickly ran into a problem. I have a class called Alarm which contains a few basic fields, e.g. name, description etc, plus some others which are references to other classes e.g. AlarmSeverity and a couple of collections. So the class might look like
class Alarm{
Long id;
String name;
String description;
AlarmSeverity alarmSeverity;
Set<Action> actions;
}
I am using OpenLaszlo for the front end - not JSP of which I know nothing - and in OpenLaszlo when the user selects a severity level from a drop down list the form field simply records the 'id' of the severity. I believe this is the same with any html select box. The select box itself is contructed by reading all the AlarmSeverity objects and constructing a list of id's and related AlarmSeverity names.
Anyway, when the user edits some basic alarm details (e.g. changes the name or severity*) and submits the form I get the Alarm id, name and description and the id of the selected severity.
When I use the POJO as the backing bean this creates a problem since it doesn't contain a field for the severityId and the 'actions' collection is set to null.
To get around this I currently use the following architecture:
In the web 'controller' layer I have a DTO called AlarmDTO which looks like:
class AlarmDTO{
Long id;
String name;
String description;
Long alarmSeverityId;
}
As you can see the AlarmSeverity property has been replaced with a Long to record the id and the collection has been removed. This DTO is populated and validated by the controller and is then passed along to the service layer for persistence. The service layer has the following jobs:
1: Use the id in the alarmDTO to retrieve the original Alarm object - assuming it still exists.
2: Copy the properties from the alarmDTO onto the Alarm POJO.
3: For each reference id (e.g. alarmSeverityId) retrieve the actual POJO to which this refers and if this is not the same as the one referred to by the original Alarm then put this new alarmSeverity object into the Alarm object.
4: Finally save the Alarm object.
A similar situation arises because the Alarm is a child of another object and all the form sends me is the id of the parent not a parent object. You can imagine the service layer routine to resolve that.
At one point I had tried to get around this by adding extra id fields to the Alarm POJO so that in addition to the AlarmSeverity property I also had an alarmSeverityId Long property. This stopped me having a separate DTO but I still had the same service layer job to do to resolve the id's passed from the form plus an extra job since the controller was setting the collection to null so I still had to reread the original Alarm and copy the collections across to the Alarm object returned from the controller. I thought doing a merge rather than save would resolve this but it didn't seem to.
From the discussions I have seen on this thread I am clearly missing something and making my life way too difficult so I would appreciate someone showing me the error of my ways and putting me on the right path.
Many thanks and sorry for the long post.