Proxy in Proxy

[Orion]

It's normal or not?

:

public class TestProxy extends Proxy
{

private var mainProxy : MainProxy;

override public function onRegister() : void
   {
      mainProxy = facade.retrieveProxy( MainProxy.NAME ) as MainProxy;
   }
}

[Tekool]

Cliff often says that there is no problem in doing so. But the less interaction you have between proxies, the less knowledge they have to each others, the easier it will be to refactor your model when needed.

A case where it is more than normal, is when you have to read data from a proxy to another. You simply cannot do it otherwise.

Conversely, when you need to "write" to a proxy from another it's often because an update to data controlled made by a proxy imply the update of another logical component of the model. In this case, it's probably better to use a notification from the proxy which initiate the change on the data, previously to register a command on this notification and to update the data of the second proxy in the command.

[Orion]

I use internal proxy only for read required data. Another way create many Command and additional Proxy in business layer.

[puremvc]

If there is a relationship between two tables in the database, there is no issue with reflecting that relationship in the Proxies that represent the data to the application.

If you refactor the relationship between two existing tables, it is almost assured that the client will be be affected. The actors that are to be refactored in the Model tier of the client will be obvious because the Proxies will probably share a similar relationship. That's a positive thing from a maintenance standpoint as long as the Proxies don't become too bloated. Of course, if they do, then it would be desirable to offload the Domain Logic work to Commands.

But the Model tier should be able to maintain its own integrity with regard to relationships between data managed by separate Proxies. Getting the Controller tier involved means that the simple approach of registering all your Commands in the Facade's initializeController method no longer holds true. Now you have two kinds of Commands: Domain Logic and Business Logic. The former maintains the integrity of the Model, while the latter is concerned with facilitating the user's valid interactions with the Model.

First, as a given, assume that your Model portability is important; that it will be reused in another application. Perhaps a desktop version of your web app. You may not be planning it now, but write it that way anyway. So, imagine your Model is actually in a separate project repository, and is used in your application as a library. Perhaps the responsibility of its maintenance will lie with a different team member who is also building unit tests against it.

That said, your teammate could include Commands with her Model project that are registered and removed automatically by any project using the Model library.  In fact you'd have a PrepModelCommand that registered all the Proxies and Commands needed. That would allow you to offload the Domain Logic to Commands in the Model package without the Model being reliant on the rest of the application for providing the Domain logic. So your application would simply need to register and envoke the PrepModelCommand from the library at the appropriate time during startup, and would not need to define any notification constants or register the domain logic commands or Proxies. Just work with them in your Mediators and Commands as their documentation indicates.

-=Cliff>