PureMVC Architects Lounge

Hi all.

I've selected PureMVC as the framework to port a large scale commercial across to -- which is currently quite a mess on the flex side.

I've read all the docs, and have my first (surely of many) question --

this application has several hundred commands and notifications.  Is it really best practice to list the constants for all of these within the ApplicationFacade class?

I'm not questioning the practice of the constants -- that makes perfect sense.  However, I wonder if this creates a maintanence issue.  Should this instead be split over seperate files?

As an alternative, does it violate any of the best practices if these are split over several static classes, all in the same namespace / package as the application facade, but broken into more logical subgroups?

These classes can then be declared as public properties within ApplicationFacade.

So, instead of referring to ApplicationFacade.ADD_EMPLOYEE, I'd use ApplicationFacade.EmployeeCommands.ADD_EMPLOYEE.

Thoughts?

Hi Marty,

Absolutely, breaking the constants out into separate files can make sense when their volume reaches a certain point.

It could also be that breaking the application itself into separate apps could be indicated at this point as well.

If you decide to investigate that route, you might sign up for the PureMVC Courseware beta test. You'll work through a set of apps using the same Model, each with their own Facade and use cases against the common Model.

And also you might have a look at the work Nate Rock has done with Modules:
http://forums.puremvc.org/index.php?topic=49.0

-=Cliff>

Great!

Thanks for the advice, and the link.

Much appreciated.

Marty