PureMVC Architects Lounge

Announcements and General Discussion => General Discussion => Topic started by: njm on March 03, 2009, 01:22:44



Title: Questions about some design decisions regarding proxies
Post by: njm on March 03, 2009, 01:22:44
Hi All,

I've been reviewing PureMVC, and have a few questions about its architecture:

  • Why do proxies have names?  I suspect this is to prevent multiple proxies of the same name from being registered.  What is the functional benefit of this, however?  Why not let users to register multiple proxies of the same class with different names, and decouple this view-specific logic from the proxies themselves?
  • Why should proxies be required to expose their data object?  Is this not an implementation detail?  I understand that a very common subset of cases will map a proxy directly to an object, but this is by no means the dominant case, and again I question why this object must be exposed at all.

Aside from this, I find PureMVC to be a very well-engineered library and would like to thank all its contributors for their hard work.

Cheers,
Nick


Title: Re: Questions about some design decisions regarding proxies
Post by: Tekool on March 03, 2009, 02:40:22
1>Why not let users to register multiple proxies of the same class with different names, and decouple this view-specific logic from the proxies themselves?

It is the Proxy default behavior. Look at the Proxy class constructor default arguments : (proxyName:String=null, data:Object=null). It's only a convention to use a constant as proxy name when you did not need to create multiple proxies of the same class in your application.

2>Why should proxies be required to expose their data object?

Not sure here, but I think it's a good practice to give access to the data when the proxy's data is a VO. You can use it as *protected* or *private* to give the data the good type in the Proxy itself. I found it useful in UnitTests to verify from the Test that the proxy acts as expected on the data.