Jeff,
Glad you liked the book. So, our 'framework' is really just a couple
of design patterns. In fact, if you simply have our commands implement
IResponder instead of extend the commandAdapter and have the Service
layer just manually add the responder to the asyncToken, you really
don't need any classes from the framework at all. (not counting the
few things we wrote for handling SQL commands, but those are easily
replicable as well)
Basically, in a lot of frameworks the controller is reponsible for
managing the call between the view and the command. We understand this
but at some point you are doing just as much work to populate an event
object or some other type of thing and send it on its way as you are
to just call the command. While this way has more coupling, it also
means it is clear where commands are called from and when a command is
no longer needed or used the linker can optimize it out of the final
file. There are advantages and disadvantages, but we like it.
As far as an enterprise app, the term gets rather overused, so it
depends on what you mean, however, there is nothing inherently
limiting about this design. As you grow it scales linearly, the
biggest challenge is just maintaining order to your views and commands
so that they still make sense. Basically, this is about the lightest
weight thing we could conceive of that helped you to organize and
structure code without imposing a lot in the way of rules.
At the end of the day, you need to be comfortable with any route you
choose, but I am only in favor of order that does not come at the
expense of innovation.
My 2 cents.
Cheers,
Mike