List Model-Service Architecture with Robotlegs

EDIT: Stupid post. I don’t know how I got it into my head that VO’s needed an abstract factory for testing. They’re Value Objects! Without the Abs-Fac we don’t need ‘IVO’ and we can implement multiple interfaces because the concrete interface is all that our system needs. Sorry if I wasted your time with this drivel.

I’m currently looking at our services and model tier architectures. I’m focusing right now on the most common requirement of the client model-service tiers at Visfleet:

• Maintain a client side representation of collection resources (Lists of like information)
• Keep the list server-canonical (allow the server to provide the most up-to-date state as often as possible)
• Expose standard REST operations for List, Show, Update, Create, Delete, New, Edit
• Expose resource specific methods (RPC when needed)

So I was looking for a prescription, that as usual, kept my responsibility-count-per-class down near one.

What follows is my first draft. (Embiggen)

Note: IUpdateable is the only non-metaclass in this diagram.

service.load

So in this example I support service.load() which fetches the state of the whole list, or part of the list, from the server. The description of sequence that follows works as easily for any service request that results in a result record coming back from the server.

1. service.load() requests a list form the server.
2. service iterates over the service results
   1. Uses voFactory.create() to create a new concrete VO
   2. Parses the server result into the VO
   3. Adds the VO to a payload.
3. service emits a signal that it has results, which carries the payload it just created.

controller (HandleResultCommand)

Typical Robotlegs behaviour here:

1. HandleResultCommand calls listModel.update() passing the payload of VOs

listModel.update()

The list model needs to ensure that its representation of the list is updated by the incoming payload

1. Iterates over the payload
   1. Adds VO to list if it’s new (not in list)
   2. Updates existing list VO if it’s an update (in list)

To update a VO, listModel depends on IVO being IUpdateable. This could be a responsibility of the ListModel itself, I’m still not sure which is more OO Savvy.

In my opinion, a broadly updateable VO is a requirement of the Flex framework. Collection types in Flex work best if VO object references don’t change. So do the collection-aware components.

The Gap

Usually at this point, someone wants to edit a VO. We don’t modify server-canonical VO’s in our apps, we clone them. We edit the clone, and actually share the clone as an ‘EditableModel’ so our whole app has access to the current VO under edit.

This is a perfect arrangement, however, I’m stuck. Making IVO ICloneable is not possible, I could only make VO ICloneable. If i move the IUpdateable respnsibility to ListModel there’s now a gap for ICloneable, but I’m not pleased with making an unassociated refactor a requirement.

If I introduce my EditModel at this point however, I do get a way around this that makes sense.

Welcome EditModel

(Embiggen)

I’ve dropped some components to make this clearer.

EditModel is introduced. It maintains the currently ‘under edit’ VO which is a clone. It uses ICloneable a little like a marker interface to do this. However it does require the VO to implement clone().

Do you think I should be making the effort to make ICloneable purely a marker and have a CloneStrategy?

Please feel free to comment, once you are aware of my usual disclaimers