On Tue, 8 May 2007, Matt S Trout wrote:
The controller's there for event dispatch and flow handling. Domain logic should be encapsulated - if anything, you want to make your domain model a completely separate piece of code with an interface model (or Facade Model) that your application interacts with.
Another way to state this is that the Controller is a bridge between the core of the app (the model) and a view _for a specific environment_. For web apps, that environment is usually CGI/HTTP requests.
But a controller could also be something for bridging CLI commands to the model (with no view per se) or maybe a GUI app, where the controller would probably the event loop and dispatching to various widgets.
One criterion for proper use of MVC would be to ask yourself "can I replace the controller with a command-line args parser/dispatcher and still use my model to do everything my web app can do". If you can say yes, you've at least made a good separation between model and controller.
-dave /*=================================================== VegGuide.Org www.BookIRead.com Your guide to all that's veg. My book blog ===================================================*/ _______________________________________________ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
