Hi Saad,
I agree with your precepts for decomposition of actors and modules. However, I think the explosion of classes in your current design is probably due to the literal mapping of your application's actors to the REST interface you are exposing to the client.
For instance, having a separate command and proxy pair for list/detail/insert/update/delete seems a bit excessive. Usually I have one Proxy for a data source and perform all operations from it. A single command could look at the incoming request and determine which methods to call on the Proxy.
I see you're using AsyncCommand/AsyncProxy. Not my favorite implementation. I like the "Formal Request" architecture (which I describe in the Advanced Model Topics section of the PureMVC book) better.
The essence of that architecture is having a "Request" object which is submitted to a Proxy, via a method like MyProxy.submitRequest( request:IRequest ). That request tells it the operation the caller (usually an ICommand) wishes to invoke. And it also has a callback function (courtesy of extending PureMVC Observer) that lets the result come back asynchronously to the caller. This will work with a SimpleCommand and Proxy.
I described the basic premise in code here:
http://forums.puremvc.org/index.php?topic=1955.msg8724#msg8724You'd want a more advanced request that could have a type and other parameters probably. That example just triggers a static call and gets the result back. It also uses AsyncToken (a Flex-ism) that ensures the Proxy gets the result of the call. Whatever methodology you're using in JS in your AsyncProxy would be used there. It has nothing to do with the communication between the command and the proxy.
I'm willing to bet you could have a single command figure out the type of request to generate, then submit it to a single proxy to get the work done and return the result. Your router would simply need to send the right notification to the command containing the information about the REST path, so that the Command could determine the appropriate request type to create. With a single submitRequest() method on the Proxy, it would mean you don't have a big switch in that Command calling different Proxy methods, so it shouldn't be very large. Nor should the Proxy really. It would need a method for each of list/detail/insert/update/delete, but its handling of the response would be similar.
The command would then trigger different notifications based on the response it gets back, which might mean a Command and/or Mediators answer, that end of things - handling of the result - will vary based on your app. But the collapsing of the commands for initiating a call into one, and the collapsing of the separate proxies for every kind of call by way of the formal request object with built-in callback should get this under control without pushing too hard at the upper limits of your #1 decomposition rule.
Show Posts
