Cliff,

Again definitely appreciate the responses.  I think my last post might have been a bit confusing in what I was trying to get across.  I was using the word core instead of kernel.  I suppose I am thinking of a system as follows:

[kernel] [1]<---->

• [modules]

1 kernel to many modules, generally the modules would work on their own name spaces.  If a module needed to talk to another module, it would dispatch a message to the kernel which would then forward it to all modules.  So system level messages vs module level messages.  I suppose a system such as this could be implemented on top of pipes, though with the tee splits you would have no need to have the kernel in between the module to module notifications.  I suppose pipes is more robust than an implementation like this because it allows modules to create their own tree structure and possibly internal pipe loops, like multistage filters.

I can understand pipes in the context of passing the output of one application to the input of another application and so on.  Very useful if you want to filter messages through another module before it actually gets to the kernel, or if you don't want to bother any other modules and just pass the output to the input of that module.

I guess my question: Is there a lot of applications that use a different tree structure model than the kernel and many cores for a multi core implementation?  Is there a lot of architectures that call for in messages and out messages to be processed by different modules? Usual scenarios I can see for a typical application:

1. Module asks Kernel for something (possibly to application config, or possibly reposition the module)
2. Module tells another module(s) to do something (possibly display a new view with the message data)
3. Kernel tells module(s) to do something (possibly refresh)

Again, appreciate the response, just trying to familiarize myself more with the reasoning for when and why I would use pipes and process input and output differently. Or is this just a design choice (as bidirectional setups can be built on this).

Thanks,

-Jason

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

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

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!