Proxy - Delegate pattern in a Multicore app, or?

[simon.hjorth]

Hi,

I'd like some advice regarding maintaining a Datamodel across modules.
The core of the scenario is more modules working on (parts) of the same datamodel, with the implications that has of keeping data up-to-date within every module in response to changes made by other modules.
For instance assume a setup where a Customer entity has Persons and Projects associated with it as well as having some other properties. One module (i.e. the Addressbook module) deals with the Customer itself, as well as adding/removing Persons on the Customer. Another module (i.e. the Projects module) works on the Customer by adding/removing Projects.

A way to handle the above scenario could be by using the Proxy - Delegate pattern.  One could make a AddressbookProxy and a ProjectsProxy, both interacting with a CustomerProxyDelegate which in turn communicates with the backend (database) system. In that way, the Delegate is in charge of keeping the model updated and delegate the relevant objects to/from the Addressbookproxy and ProjectsProxy.

How would such a setup work in a multicore app? How would the Proxies of the different modules retrieve the Delegate? Is such a setup desirable or is there a better solution?

Any idea/help is welcome :-)
Thanks in advance

Regards,
Simon

[puremvc]

First of all if the delegate is going to be passed shared by the service module and the other modules or the shell, then the class needs to be shared by all the modules, and needs to be defined in a separate library. Then your problem becomes how to get a reference to the delegate, which brings us to inter-core communication methods. (A core is the shell or a module)

There are 2 ways of handling module communications with MultiCore: interfaces and pipes.

With the former, the module implements an interface known to the other cores that will communicate with it. They get a reference to the module and make calls against this interface. A 'getDelegate()' method on the service module's interface springs to mind. Another idea is to drop the sharing of the delegate and just expose the delegate methods on the service module's interface, passing calls through to the actual proxy/delegate following the facade design pattern.

The other comm method is pipes, which is always async between cores. You send a message down an output pipe, and forget about it. Later, another message shows up on an input pipe. You don't care about where it came from, just what's in the request and response messages. I like this because it achieves the highest level of code separation. Your modules must agree only on the entity classes and the message classes (which end up in your shared library). You construct your own message protocol to fit your needs. And it best supports third party development of modules that work together.

Hope this helps,
-=Cliff>

[simon.hjorth]

Hi Cliff,

Thanks for the response and advice :-)
The two ways of inter-core communication you're mentioning were also the options I've been considering, given my knowledge so far of Puremvc multicore. However, I wasn't sure which way to go in the case of sharing a Delegate/Data model between modules.
Thanks for shedding some light on that issue. As I'm already working a bit with pipes, I will probably try that direction, albeit it can seem a bit cumbersome at times constructing and passing notifications instead of just calling methods on an interface.
As a side question: Does it makes sense to combine the interface and pipes ways of communicating? i.e. all modules (at least all modules in need of it) will know of the service module and the interface it implements, and have a reference to it, whereas those same modules will intercommunicate through pipes if they feel they have relevant information to share or listen to/absorb?

Regards,
Simon

[puremvc]

Sure, you can mix and match pipes and interfaces. What you're describing is perfectly fine.

-=Cliff>