puremvc
|
![](http://forums.puremvc.org/Themes/PureMVC/images/post/xx.gif.pagespeed.ce.G0yTW6LI8E.gif) |
« Reply #3 on: February 15, 2010, 10:24:01 » |
|
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>
|