Ok, tough questions…

The reason I utilize my AdminController the way I do is from where I came from. When I first started attempting to do MVC in Flash, my Controller, my version of it, ended up being a bunch of code to manage data and data calls(Model), and my components (Views) on frame1 in Flash; effectively, the only code on _root was my Controller.

Over time, as I managed to get my Model more to be it’s own classes, included a few abstrations from the actual place it was coming from (.NET via Remoting, Java via OpenAMF, etc.), and started implementing a stricer event strucure, the only thing that didn’t change was what I considered my controller; the code that managed to the 2; responding to my View events, shoving in Model data to my View(s), and performing other app specific commands.

The problems I ran into, however, is my Controller, while more organized, was unweidly. It started to be come thousands of AS lines long, and was really really hard to manage.

So, when I started utilizing ARP, I found I liked Commands because a lot of the Controller logic was now easily seperated off, segrated into a more organized & easily findable class, and I could re-use it (some of them anyway).

So, it doesn’t feel tightly bound at all to me, although, I’d appreciate it if you’d suggest how I could further reduce it (and no, ViewStack’s don’t count… I know, beggers can’t be choosers, but still).

The Commands that take parameters were created for a specific purpose; perhaps had I spent longer than 8 days of spare time, I might of made them more flexible via the params… but, I doubt it; again, to me, Commands feel like Controller organizers, and perhaps I am viewing them the wrong way, but it feels good currently.

As far as attributes, if I was too specific in data, it was probably for debugging purposes since AMFPHP + Flex isn’t battle tested yet, but yeah, I agree; if you have a VO, use it as a class, not as a vanilla object AS1 style.

If you have any more suggestions, it’d probably help me to hear them. Thanks again for taking the time.

I don’t quite get your implementation of ‘Controller’ here … rather than the controller that Sho was disputing, you have an AdminController that contains your view (MXML) and a bunch of method calls on the view (such as doDeleteUser() ) that in turn invoke commands.

So – rather than gain the benefits of the controller as a means of separating the implementation of your view from the underlying implementation of your business logic, you have a pretty tight binding here between the view and the commands. To be honest, I don’t really see what benefits your gaining from the controller. Shouldn’t it be the case that your view code (MXML) simply dispatch events, safe in the knowledge that somewhere there’s a controller listening to, and responding to those events ? This makes reuse of commands a piece of cake, and completely independant of your view implementation. Passing the current view (‘this’) to your commands seems to require that your commands have some knowledge of the MXML view that called them as well … I can’t understand why it would be necessary that your commands have reference to the view, especially given you adopt the strategy of a global Model class (why don’t your commands simply manipulate the model, and let your model bind to the view ?).

I also note that your runCommands take arbitrary lists of parameters; why not use your value objects as the data to pass to command calls, so that your commands are not so brittle to the params passed in ?

Similarly, I’d suggest that your delegate methods accept value objects as curreny, rather than individual parameters; pass in a TodoItemVO to todolistsDelegate.createTodoList(), rather than list out all the attributes ? Thoughts ?

Steven