Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

| * |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / Architecture / Chaining IResponders by adding multiple of them with asychToken.addResponder() on: August 13, 2008, 02:55:35
For any remote call (which is how all real work is done in our app) there are two types of things that need to happen:
- Domain logic: updating the model and other stuff related to the domain / data
- View logic: displaying messages and showing and hiding progress indicators etc. 

I was thinking of having a responder to handle the Domain logic, and one for view logic.  Both basically need to know what happened in any remote call.  So I chain them such that the View (pureMVC Mediator) asks the Domain Model (pureMVC Proxy) to do some domain logic.  In the low level remote service call code we add these two responders with the Domain Responder first.  Then the call happens, and it should fire the domain responder then the view responder.  Either one could send notifications or whatever if there are other interested parties. 

So questions are:
- Is this a horrible idea? 
- Is it not very PureMVC?
2  Announcements and General Discussion / Architecture / Arch considerations: the Model, Remote Service calls, Proxy, lots of DTOs on: July 24, 2008, 01:52:57
Hi All,

Thanks to the creator, Cliff, for this framework.  I am architecting the Flex UI for a brand new enterprise app that will evolve to be very complex.  I selected PureMVC over the other contenders. 

The thing my brain is wresting with is the Proxy and it's intended use. 

We have many DTOs sent to and from the server (java).  We generate AS3 versions of these.  We also have a set of service beans like UserManager, AccountManager, etc which return these DTOs and take them as arguments (and we generate service stubs for these too).

This is all well and good but I am trying to figure out how the Proxy fits in.

1. Proxy for each DTO?
We have like 40 DTOs already (and this will grow).  I don't think I want to have a proxy wrap each DTO as it's internal "data".  Maybe I am misreading the intention of the proxy? 

The main things the proxy seems to provide, in terms of it's connection to to the rest of the framework, is that you can look them up by name and they can send notifications (which I can do with AppFacade anyway). 

2. Proxy makes remote service calls?
Something about the model talking to the server just seems weird to me.  I donno, just feels more like a controller type task.  I guess I was thinking the model is more like an object graph, and the services (web for now, but could be other persistence framework later) act on these beans to get/set whatever on them.  Do people really have these "smart" proxies that go and fetch data from services and throw events when it is done?  I guess it kinda makes sense that the Proxy may get data, set it on itself, and throw an event (just cause of the set it on itself part), but still feels like code I would put in a service layer or persistence layer or something -- basically a set of services the Controller (or whoever) users. 

Am I missing something?

Thanks for any help and for the well thought out framework.

Pages: [1]