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

Pages: [1]
Print
Author Topic: Arch considerations: the Model, Remote Service calls, Proxy, lots of DTOs  (Read 10287 times)
andrew
Newbie
*
Posts: 6


View Profile Email
« 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.


« Last Edit: July 24, 2008, 01:58:06 by andrew » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: July 24, 2008, 05:10:09 »

I would suggest a composite model hierarchy managed by a fewer Proxies htan the number of objects, assuming all these transfer objects are related.
I'm fairly sure the reasoning for the proxies communicating with services is discussed in the Framework Overview, and Best Practices docs, as well as throughout these forums. Please let me know if you don't find it there and I'll try to go into it more when I'm at the computer.

-=Cliff>
Logged
andres
Jr. Member
**
Posts: 14


View Profile Email
« Reply #2 on: July 24, 2008, 05:57:02 »

I think it's really up to you.

In PureMVC it is totally fine to place your service logic in the Model layer. It really simplifies many things and speeds up development in many projects.

But recently I've been taking a semi-Cairngorm approach and delegating service responsibility to the Controller layer, which I believe is also allowed in PureMVC (I just don't know if its documented). The controller would retrieve data from the server and update the model/domain layer with the data retrieved from a service. I have a Proxy for each DTO (or Value Object), which is fine cause I see a Proxy as a sort of 'Manager' for a particular DTO. For example, the following UserProxy is responsible for storing a list of UserVOs and provides methods for retrieving specific UserVOs and methods for modifying them.

UserVO:
    name:String
    id:int
 

UserProxy:
    private _persistWithServerMap:Dictionary;

    storeUsers(userList:Array):void
        this.data = userList;

    getUserByName(name:String):UserVO

    getUserById(id:int):UserVO

    updateUser(modifiedUser:UserVO):void
        var user:UserVO = getUserById(modifiedUser.id);
        user.id = modifiedUser.id;
        user.name = modifiedUser.name;
        this._persistWithServerMap[user] = true;

    //A Command would read the contents of this Dictionary to update the server
    //with only the UserVOs that were modified
    get persistWithServerMap():Dictionary
        return this._persistWithServerMap;


If you find that you don't need a Proxy for each DTO, I guess you could simply create a Proxy for storing groups of DTO types.
Logged
andrew
Newbie
*
Posts: 6


View Profile Email
« Reply #3 on: July 25, 2008, 03:13:05 »

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...

« Last Edit: July 25, 2008, 03:18:47 by andrew » Logged
andrew
Newbie
*
Posts: 6


View Profile Email
« Reply #4 on: July 25, 2008, 03:26:02 »


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).


Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: July 26, 2008, 04:56:12 »

You're on the right track. If you think about EJBs, there are no Commands involved in their persistence. The separation of your domain logic from your business logic will give you a more portable Model.

-=Cliff>
Logged
Pages: [1]
Print