1

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!

loneboat
  • 2,845
  • 5
  • 28
  • 40
  • possible duplicate of [Understanding MVC: Whats the concept of "Fat" on models, "Skinny" on controllers?](http://stackoverflow.com/questions/3109715/understanding-mvc-whats-the-concept-of-fat-on-models-skinny-on-controllers) – Gordon Jan 28 '11 at 15:49
  • @Gordon, I think the two questions are related, but aren't duplicates. – Moo-Juice Jan 28 '11 at 15:51
  • I'd say this question largely overlaps a subset of the referenced question (I can't type a Venn diagram, unfortunately), but with a more specific scenario being presented. – David Jan 28 '11 at 16:09
  • just a thought: There's no need to close your own question. Just marking an answer as accepted (as you have done), is enough. So it's "closed" from an "accepted answer" point of view, but remains open so that others searching Stackoverflow can benefit from it :) – Moo-Juice Jan 28 '11 at 17:34
  • @Moo-Juice: Well, I think I've just demonstrated my ignorance of how closing SO questions works. :-( All I did was mark it as answered, but I thought that WAS closing it. Anyway, thanks! – loneboat Jan 28 '11 at 19:16

3 Answers3

5

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.

Moo-Juice
  • 38,257
  • 10
  • 78
  • 128
  • +1 Agreed. The Model should be independent of the application context that's running it. The Session, being part of the application context, belongs in the Controller (which is what the particular application uses to talk to the Model). Anything a Model needs should be supplied to it in an application-agnostic format so that any application can use the same Model within the domain. – David Jan 28 '11 at 15:57
  • @David, agreed. If the Model contains session state, it can no longer be used in any context other than a web-browser and your choice is to re-design or fudge a session state. If it starts life without it, it's a breeze. – Moo-Juice Jan 28 '11 at 16:07
  • I agree to injecting the data but I disagree that session state belongs to the controller aka presentation layer. The data stored in the session is Model data. – Gordon Jan 28 '11 at 17:29
  • @Gordon, the *data* stored in the session object *pertains* to the Model. The *Session* object does not belong in the Model. – Moo-Juice Jan 28 '11 at 17:34
  • @Moo The Session superglobal provides access to persisted data, so it belongs to the persistence layer. And that's part of the Model. It's not even true that a Session couples to the browser, because you can inject your SID as a CLI arg and reconnect the Session data with `session_id()`. – Gordon Jan 28 '11 at 18:30
  • @Gordon, we may have to agree to disagree on this one :). Session data is only "persistent" in a *transient* way. It has nothing to do with the business *model* whatsoever. Just because it has a notion of persistence, doesn't mean it should be in the model. Static variables are more persistent than session variables, should they reside in the model too? :) – Moo-Juice Jan 28 '11 at 18:45
  • @Moo Yes, we have to agree to disagree ;) – Gordon Jan 28 '11 at 18:58
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.

Gordon
  • 312,688
  • 75
  • 539
  • 559
Gregory A Beamer
  • 16,870
  • 3
  • 25
  • 32
1

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.

Gordon
  • 312,688
  • 75
  • 539
  • 559