what is the differences between Proxy & Delegate ?

[nisimjoseph]

hello,

first of all i want to indicate that i am almost finish to study the PureMVC and the simplicity is great and not take a lot of code and compiled space. so thank you Cliff!

now to the question. we have the Proxy "layer" that get the data from the server and send notification to the app for getting the new data.
what is the deference's between Proxy & Delegate ? i know that Delegate need to be the middle layer between the Service layer and the Data Model layer, and this is what the proxy do - go to the server with the Service layer and get notification from the Service layer for "result" from the server, arrange the data to app objects and notify the app on the new data.

i need some help here to fully grasp this things.

10x,
Nisim Joseph

[puremvc]

The Delegate pattern *can* be used with the Proxy, but isn't always necessary.

If a given Proxy is the only Proxy that needs to access a service, then the Proxy may act as both the invoker call the service and  responder. There is no need to separate the invoker and responder in this case, nor to move the service handling into a separate class.

The Delegate can be used if you have more than one Proxy that needs to access the same service.

The Delegate handles the invocation for the Proxy and sets the Proxy as the responder.

Many implementations of the Delegate pattern in the wild are actually instantiated once for each caller and provide a separate service object that is being used solely for that caller. This is pretty wasteful since you can reuse a Flex service object for multiple callers use the AsyncToken pattern to sort out which returns go to which callers.

So actually a good way to handle this in PureMVC entirely with Proxies is to register a Proxy that acts as the Delegate. Other Proxies call methods on it passing themselves to be used as the responder.

Why is ths any better than having a Delegate that does the same thing? Because its long-lived, easily retrievable, and only one service object is used.

-=Cliff>

[nisimjoseph]

ok, got that!

i think that you answered my next question. so thank you on the next one as well.

Nisim

[dbasch]

Many implementations of the Delegate pattern in the wild are actually instantiated once for each caller and provide a separate service object that is being used solely for that caller. This is pretty wasteful since you can reuse a Flex service object for multiple callers use the AsyncToken pattern to sort out which returns go to which callers.

So actually a good way to handle this in PureMVC entirely with Proxies is to register a Proxy that acts as the Delegate. Other Proxies call methods on it passing themselves to be used as the responder.

Why is ths any better than having a Delegate that does the same thing? Because its long-lived, easily retrievable, and only one service object is used.

-=Cliff>

Yes, exactly! I wrestled with this issue several months ago and found a similar solution. I started using Proxy objects as proxies (or delegates) for service endpoints.

One Proxy for the data set being managed (Chair inventory) and another for the service endpoint (Chair service) being managed.

As always though, Cliff did it better than I could have. 

One last note, there does not seem to be a good example of using a single Proxy as both invoker and responder of an asynchronous service call. All of the examples use either hard coded VO's or use the delegate pattern.

Cheers,
Derek Basch

[dbasch]

One last note, there does not seem to be a good example of using a single Proxy as both invoker and responder of an asynchronous service call. All of the examples use either hard coded VO's or use the delegate pattern.

I take it back. I found the Code Peek demo under the AIR examples. It uses a "SearchProxy" and a "DataProxy".

I usually name my proxies something like this:

Data Proxies:

• VegetableProxy
• CowProxy
• ChickenProxy

Service Delegate Proxies:

• FarmServiceDelegateProxy

[JJfutbol]

I never thought of proxies this way but an interesting way to use them. What I have done and feels most familiar is I create a proxy for each entity I'm managing. If I need to manage users I have a UserProxy. If I need to manage comments I have a CommentProxy.

I strongly suggest the use of the Delegate pattern since it can be a useful and yet further abstraction. For example, if you don't yet have a service to interact with, say the service is being built alongside the client, the delegate can work with a dummy XML file. Once the service is setup you can just start hitting the real service by editing that single file! Very handy!

Another suggestion is that from a single service you might be working with different entity data. For example, a directory service might return identities and organizations. If you are in need of managing both it might be useful to treat each individually in IdentityProxy and OrganizationProxy but then have a DirectoryDelegate which houses the service object for interacting with the directory service. Another handy reason to use a Delegate!