Proxies API like DAO?, Cloning Objects of VO sets

[jasonengr]

Hello all,
 
Assuming I am using a Flex/BlazeDS stack and am returning VOs to the proxies through a service and I need to massage the data for different views.

Say I have a collection of 50 VOs with a type field.  Is it reasonable to have the proxy API take care of returning different sets of the data? So say I have UserServiceProxy.getCollection(type) and this returns the list of VOs I need of that particular type.  Or should proxies be very dumb by default and provide the entire collection to manipulate? I am leaning towards Option 1.
 
Further if I don't want the base VO set modified, should I clone these before leaving the proxy (this is what I am assuming is correct) or should I clone them in the mediator before passing them to the view?
 
Option 1
If we have 3 views, ViewA, ViewB, ViewC.
 
ViewA Mediator needs type A VOs, so UserServiceProxy.getCollection(A); // 15 cloned VOs of type A

ViewB Mediator needs type B VOs, so UserServiceProxy.getCollection(B); // 15 cloned VOs of type B

ViewB Mediator needs type B VOs, so UserServiceProxy.getCollection(C); // 20 cloned VOs of type C

 
Or should I go with

Option 2
ViewA Mediator get the full collection, iterate over it and store and clone all A VOs.

etc...

In comparing it to a DAO architecture

http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Do proxies act like a DAO (adapting the service calls to the model)? Or should proxies be more of just the data source and then have DAOs act as a layer above the proxies?  My assumption is the proxies API is like the DAO API and allows the model to be decoupled and able to change independently of the system while the proxy API stays the same.
 
Thanks!

[puremvc]

The Proxy can act similarly to a DAO with respect to the other PureMVC actors. It is indistinguishable for all intents and purposes. It's just that for what was originally a client-side framework, a more generic pattern was desired; one with no server-side connotations that might be confusing. Of course PureMVC can be used in the server environment as well, where its implementation might actually resemble that of a typical DAO, slinging gobbets of SQL at databases and the like.

Regarding your implementation, I think you're on track with option 1.

Don't push that sort of work into the Mediator. It should remain in the Model region. You could put it in a Command, but unless you're very careful (as I'll describe below) you're likely not to be able to reuse the logic easily in another application. Always remember the first rule of RIA client development: you might reuse the Model in multiple apps (mobile, web, desktop). Therefore, you want Domain Logic like getting clones of all the VOs matching certain criteria to belong to the Model region.

That doesn't mean that the Proxy has to become a 1000+ line monster class with all that code living inside it. And it doesn't mean you have to write an amorphous 'helper' class to do it. The litmus test of whether your domain is properly self-contained is if all its classes can be moved to a library and reused in another app.

You can write Commands which the Proxies use to offload some of their Domain Logic work. They may be registered by the Proxies themselves, or you might have an InitializeModel command contained in that library and that's all your app project needs to register and invoke to properly register all the Proxies and Commands for the the Domain Model.

So your ThingyVOProxy could expose a method getClonedCollection(type:String) which rather than doing the work itself, sends off the notification for the appropriate Domain Logic Command. Mind your notification namespace; register the GetClonedThingyCollectionCommand to a note name like: "MyDomainModel/Thingy/GetClonedCollection"; this insures no collisions with other Commands used elsewhere in the app, and further ensures portability of the Model, even to third parties.

So... 
*  Call thingyProxy.getClonedCollection("B"),
*  The Proxy sends this GET_CLONED_THINGY_COLLECTION notification (containing a reference to itself in the body, so that the command doesn't have to go to the trouble to retrieve it)
*  The GetClonedThingyCollectionCommand is fired, and it gets the Proxy's complete collection from a getter on the Proxy.
*  It rips through the collection, creating a new collection of clones of the VOs matching the type,
*  It calls a setCurrentResult property on the Proxy, passing the collection of clones,
*  Since Flash is single threaded, we are back in the thingyProxy.getClonedCollection() method on the next line after we sent the notification, where we simply return the private currentResult property.

-=Cliff>

[jasonengr]

Cliff,

Many thanks on your response here.  It was very helpful.  The only question I would have going forward on the solution you proposed is that the PureMVC best practices talks about keeping your domain logic inside the model. 

With this implementation that command is required for any implementation of that model and it is still easily movable to a new library which makes sense.  Is it acceptable to have some commands that work on domain logic and some that work on business logic?  I would assume that you wouldn't want to have both in the same command, as this would tie the domain logic to that application. 

Thanks,

-Jason

[puremvc]

Is it acceptable to have some commands that work on domain logic and some that work on business logic?  I would assume that you wouldn't want to have both in the same command, as this would tie the domain logic to that application. 

Definitely, but as I mentioned above

You can write Commands which the Proxies use to offload some of their Domain Logic work. They may be registered by the Proxies themselves, or you might have an InitializeModel command contained in that library and that's all your app project needs to register and invoke to properly register all the Proxies and Commands for the the Domain Model.

In order to keep yourself honest and sure that you aren't 'crossing the beams' of Domain and Business logic anywhere, you should break your Model-related classes off into a separate project which has no dependency to the classes in the main application. Give that Model library its own PrepareModelCommand that registers the Proxies and Domain Logic Commands. Have the app import the Model library and simply register and invoke PrepareModelCommand.

-=Cliff>