I know this is probably a pretty obvious answer because I am missing something, but why would one use a pipes implementation rather than bidirectional notes directly to the core?  The premise fascinates me but from my initial understanding seems to be more complicated than needed in most application structures.  I could see it being very powerful in a case where you want to process in going and out going messages very differently, but how often do you see that?  I have only worked on one pipes project, so it would be interesting to understand how this might be useful in other situations. 

I see 4 usual cases, module talks with core, module talks with specific other module, module broadcasts to other modules, and core broadcasts to module.  It would seem simple to create an architecture that used the core as the router, having system level notifications versus core level notifications without worrying about tee splits going in and out.

I suppose multicast messaging, where you need a subset of all the modules to receive a message would be a good case for pipes, though I would only see this to be very valuable over broadcast in systems with a large amount of modules.

Thanks,

-Jason

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!