I really don't see much ambiguity myself. I'm not really a theorist on this stuff, so what follows is my practical definitions based on working with it:
Model(s) - Data source abstraction. You put things like access to RDBMSes, Files (collections of images?), and even remote data sources served via XMLRPC or screen scraping here. The point of this layer is to encapsulate and abstract the access methods for the data sources, and do simple transformations that are directly related (for instance, translating between DB timestamps and DateTime objects, or calculating a user's age based on the stored birthdate in his database entry). The best way to determine if a peice of code belongs in a Model is to ask yourself: "If someone were to write a completely different application for a completely different purpose using a completely different architecture (perhaps not even web-based at all) which also needed access to this data source, would this peice of Model code probably be appropriate and/or useful for them?" Views(s) - View-windows on your application. In theory, you might have several views: an HTML view, a graphing view (for outputting GD::Graph images), a PDF view, etc. The only knowledge that belongs here are the details involved in constructing the specific flavour of output. If you find yourself putting code in your View templates that isn't directly related to rendering this specific flavour of output, it probably needs to be moved to the Controller. Good code in views: iterating an arrayref to generate a <ul> list, walking a data structure to generate a <table>, or walking a data structure to generate a graph image. Controller(s) - This is the glue that binds Models and Views together. It accepts user input, possibly makes modifications to Model data, possibly retreives some Model data, and then displays a View at the user who gave the input. This is where the business logic goes. This is where anything that officially doesn't belong in Views and Models goes, basically. If you find yourself putting any HTML tags in your controllers, that code really belongs in your Views. Similarly, if you find yourself putting raw SQL or raw requests to remote network sources, etc in your controllers, those really belong in proper Models. That's the ideal situation in my mind. Obviously in the real world you sometimes deviate from this, for reasons like "I don't have time to design the proper abstraction before this looming deadline", or "doing it the right way is just provably too inefficient in this particular case". But its important to keep the ideal in mind and strive for it. -- Brandon _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
