Great article on the misunderstood scope of the “Model” in the Model-View-Controller architecture. The takehome: Models are commonly thought of as wrappers for database access/stored objects, but application state and business logic need to go in them, too. Otherwise you get bloated controller and/or views that clumsily try to take care of these concerns.

Earlier today I was building a multi-step wizard app—no DB storage—and found my controllers getting messy with session and state handling code. The solution was a Wizard class that encapsulated the steps through the forms and the maintenance/validation of the collected data, but until this article I might not have thought of it as a model.

Zend Framework kinda, sorta has a hack for making a wizard using “subforms” and what makes this an awkward construction is that a view helper is not the best place to maintain the state info that a wizard requires. A “Zend_Wizard” class would need to encapsulate several forms; requirements and behaviors for moving forward and backward through the forms; and methods to inc/dec the step state, fetching the active form injected with session data. Only a single controller would be needed with 2 next/back methods, rather than methods for each step.

In the Elgg plugin ecosystem, there’s very little guidance/emphasis on creating models, so writers rarely encapsulate business logic at all. Instead it becomes spread out amongst controllers and—worse—views. Since views can easily be overridden depending on the order of plugins in a list, business logic can easily be mangled by logic from another plugin. That said, the view system does allow mods to mix behaviors in ways that would be difficult were views to be tied more closely to individual plugin models; a few exemplary mods—that store state and validation in a model rather than the controller/views—might help positively influence the culture.