service-layer interface for domain object binding

[assaf]

Hi all,

It'll probably come home to me one of these days that if I want an answer I should post a straightforward question rather than first posting tons of code (as in my previous posting) :wink:.

So, here's my question:
I have a form where the user manipulates a whole hierarchy of child objects under a single parent object.
I want to create a fairly thin service layer as a transactional boundary.
I need to somehow bind the incoming data to my whole hierarchy of domain objects.

I could let the Spring SimpleFormController bind directly to the domain objects, but then this happens in my UI layer, outside of the transactional context. So this implies loading the parent object in one transaction (touching all required collections), and then persisting the parent object in another transaction. Which seems a bit messy.

So, how are other people designing the interface to their service layer?
Does Spring bind to the service object using setProperty?
How does the service object then bind to the domain objects?

BTW, I thought of writing a service interface which simply takes a Map of parameters (e.g. request.getParameterMap()) and performs Spring DataBinder binding internally to the domain objects. Does this seem like a reasonable approach?

Best regards,

[assaf]

Answering myself, with my latest thoughts on the subject, having attempted to Springify one of my most complex UI forms:

1. Binding generally involves translating HTML-specific data representations into domain object manipulations (property setting, child object addition/deletion). Therefore, binding rightly belongs in the UI controller, NOT in the service layer.

2. Domain objects should be able to cross layers, and be used in both the UI and Service layers. However, their use in the UI layer should be limited to binding & displaying: i.e. setting/getting properties and possibly adding/deleting child objects - all business methods should be via the service layer.

The simplest way of only exposing certain domain object properties to the UI is to place their implementation in the same package as service class implementations, and protect all business methods. I suppose another option would be to have them implement a simple external interface and a more complex internal subinterface.

In order to allow the UI controller to bind directly to domain objects, the downside is having to load them in one service layer transaction and persist them in a separate transaction. This implies touching all required collections when we load. This seems like a reasonable sacrifice, if it allows us to respect points 1 & 2 above.

Any thoughts?

[tentacle]

If I were you I would store the object graph in the HTTP session before rendering the manipulation screen. When submitting you can then get the object graph from the HTTP session. If you are using optimistic locking this will ensure concurrent updates are detected when persisting to the database.

Par contre, votre anglais est impecable