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?

What is the server technology you are using?  If there is some remoting technology available for that platform like BlazeDS then you can maintain one set of DTOs or VOs or whatever on the server, and then use some tool to generate the AS3 version of this code.  These DTOs are simple "bags or getters and setters" and are totally anemic and don't have behavior. 

If you want, you can wrap these with more functional objects on the client (decorator pattern), or you can use the proxy construct for that.  But the DTO concept is pretty powerful in Flex especially when working with a Java backend because you can tightly couple the client and the server.  Now on the server, these DTOs are probably in a different layer than your "real" domain objects.  They exist for communication to the client, or with other web services.

We send back full DTO object graphs where things like Account contains Users which contain Roles, etc.  And it works out well.

I think this is a good idea generally speaking.  I started to do it this way, but since many of the classes that need to send and receive notifications already had ApplicationFacade imported, I found it a pain to have to add the Notifications import.  This is really just because Flex builder is lame (or maybe I am), and command + shift + o doesn't seem to work (but type ahead with code assist does work).

I have all my notifications starting with a prefix.  Mine is AEV_ for "application event".  This helps with search and replace and finding things.  If you have something like "login" you will find it everywhere.  Again, this is also because the Flex builder sucks for re factoring and misses things all the time. 

Just realizing that if I go with this "smart self-retrieving-and-persisting" domain model (proxy) approach, I will likely have a fat, non-anemic domain model with some business logic.  I generally like this when working on the server, but wondering if this will result in too much controller-ish code in the model.  I think the trick will be making the domain model have "domain logic" and keeping other stuff related to coordinating the UI in the Controller.  The PureMVC best practices docs talks about this.  I think it can work well.  For example, an AIR app may have a different UI and perhaps the controller coordinates things differently, but the domain should be the same (I think).

Thanks for the replies.  I am playing around with this, and while I am sure my approach will evolve over time, here is what I am thinking:

- For each of the services on the server (UserManager, AcctManager, etc), we are going to generate an AS3 service delegate thing that does the remote object call.  This will give us a little tighter integration and reduce human errors when calling remoteObject.someJavaFunctionOnServer (we can generate this using reflection against the Java services).

- The generated AS3 service objects can be used by whoever. 

- There will be Proxy objects for different areas of the domain model (each owns a bunch of related DTOs). I am going to call them Model objects, since this is like the "domainModel" for the app.  These proxies / domain model will know how to get themselves from the repository and persist themselves.  In this case the "repository" is the server, so they will use the Service objects to do their work. 

- The proxy/domainModel objects will have functions like fetchXXX, which will call the service object passing in some response handlers.  The handlers will basically set the responses on the proxy and then send a notification to the rest of the system that the data is ready, so they can call getXXX now.  Not to psyched on this pattern for async calls but not sure what else to do.

The domain model (proxies in pureMVC speak) knows how to get itself from, and persist itself to the server (maybe this can become a local DB for for an AIR app later).  The domain model is sorta similar to a J2EE/EJB3 domain model that is annotated and can persist itself to the DB via JPA annotations.  So this sorta fits in line with an architectural pattern I am familiar with.... sweet.... maybe this will work.

On we go...

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.