MVC & Program State - Should Models be Dumb?

Question

I'm using a framework which uses the MVC paradigm. It's CodeIgniter, but my question isn't about the framework specifically - it's more generally about best practices when working with MVC.

I'm using $_SESSION variables to maintain some state variables (user selections, some temporary preferences, some data filtering options). This is easy enough to do, but I found that I was splitting the use of these variables across both models and controllers. Sometimes I would update one in a controller, and look it up in a model. This started to "smell" funny, because it occurred to me that it might not be a good idea to make the models "aware" of all those settings. Shouldn't the models just accept requests for fetching/manipulating data, and only be concerned with what was explicitly in the request (without having to look up external variables)?

Here is an example: I have one session variable called $_SESSION['regionFilter']. This is created and updated in a controller, and represents a sales region the user wants to "drill down" to. When a controller requests some data from a model, I'm currently having the model look up the $_SESSION['regionFilter'] variable, and use it when it's creating its SQL for the database. It seems like it might make more sense to make the model "dumb" regarding program state, and have the controller somehow bundle the $_SESSION['regionFilter'] variable into its request if it wants it.

Any thoughts? Thanks!

---

Edit: Thanks for the discussion, folks. I'm aware of the overlapping questions, but had a hard time finding a general discussion on the topic - my searches for "MVC model program state" turned up slews of questions about ASP.NET-MVC-specific discussions which were mired in implementation details.

I've marked the question as closed. Thanks again for your thoughts!

Answer 1

I think you're quite right in worrying about it smelling funny. You've just introduced something that has nothing to do with the model, in to the model.

I don't see anything wrong with providing a filter to the model, perhaps something that takes a string that represents your region. If you want to pass the session in to that, then feel free, but by putting the session stuff (even reading) in to the Model, you've intrinsically linked the two... A model to a session state.

Provide a method in the Model that will filter appropriately, and then by all means pass in a session variable from the controller, but the model has no idea that the filter came from the session variable. It's just a filter.

EDIT: To clarify, I'd say that session state is part of the controller, definitely not the model.

Answer 2

In general, I have domain models that are state only. I know this does not bode well with some purists of Evan's theories, but it works well for creating models that are portable, even across heterogenous systems. This works well for SOA, in other words (although we can argue whether the surrogate pattern is superior at a later date?)

When you move up to MVC, you are dealing with a UI model and not necessarily a domain model, alhthough way to many samples blend the two concepts. Your model is a model that is married to a view (a ViewModel in the MVVM pattern). If you have this logical separation, your view model can be a combination of the original "model" (domain model?) and any other information you need to display. This makes a clean separation of concerns also, which is nice.

Answer 3

If your Region Filter is required inside your Search class, then use Dependency Injection to pass it into it. Your Region Filter should actually be a Domain Model class. That Region Filter should be unaware of where you store it's data between Requests. Just make sure the Region Filter has it, when it needs it.

As a Domain Model class it does not belong to the Controller, but the Model. Note that the Model is not just the database, but everything except the UI. The controller is part of the UI layer. It's only purpose is to delegate the current Request to the appropriate models.

In other words, you should be doing something like this:

public function searchAction()
{
    $customerSearch = new CustomerSearch;
    $customerSearch->setFilter(new RegionFilter($_SESSION));
    $results = $customerSearch->fetchResults();

    // do something with $results on User Interface
}

Note that I do not agree to the answer given elsewhere on this page that session data or state belongs to the controller. It doesn't. Session data is just persisted data. Like any other persisted data, it belongs to the persistence layer (which is also part of the Model). Forget that it is Session data. It is Region Filter data.

It makes sense to slap an API around the $_SESSION (or any superglobal) to prevent coupling to a specific environment. But a RegionFilterStorage_Session class would still be a model class.