4

I have read that the Model is responsible for maintaining state among HTTP requests, for example in this article:

The Model is responsible for maintaining state between HTTP requests.

Basically any data whether on a database, in a file, stored in the Session, or cached inside APC must be preserved between requests and thus forms part of the state of the application at the time the last request was completed. So always remember that the Model is not just the database. Even the data you get from web services can be expressed as a Model! Yes, even Atom feeds! Frameworks which rattle off introductions to the Model, almost never explain this upfront which only exacerbates misunderstandings.

When we use some implicit Session objects (say in PHP, JSP etc.,) does it mean that this Session is a Model object?

Improve this question

1 Answer 1

Reset to default
0

From Wikipedia:

The model manages the behaviour and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller). In event-driven systems, the model notifies observers (usually views) when the information changes so that they can react.

That's the simplest definition of what a model is. If your session object has the facilities to respond to requests for information about its state and to instructions to change state, then you can definitely call it a Model.

It doesn't matter what the data storage is, remember that patterns are high level abstractions that are not supposed to be tied to specific implementations. You can build your models around every data storage facility, whether it's a database, some text files, LDAP, etc.

If it has the above discussed functionality, it's a model. Now, if it's a good / useful / efficient model it's a whole other discussion that greatly depends on how you use it.

Improve this answer
7
  • The definition you have put in is correct - but the interpretation you have to taken is quite over defining. Just because HTTP is stateless transportation, for managing conversation, one need to preserve session in terms of references; if you would do the same thing other than HTTP, you would have a different form or reference. This doesn't have any implication to how basic information is represented' and hence it is NOT model.
    – Dipan Mehta
    Nov 1, 2011 at 18:55
  • And what is the point of having references if they don't do anything else? Sessions are a mechanism of maintaining state, that's true, but that doesn't mean they aren't data storages. Think of the most common scenario for sessions, user state. When you actually put the info of whether a user has logged in or not in a session variable, you are have your self a nice little model. You ask that model if the user is logged in or not (requests for information) and you can tell it that the user is now logged in or off (instructions to change state)...
    – yannis
    Nov 1, 2011 at 19:08
  • So essentially the question boils down to is that you refer to information as - {list of transactions} if user_auth. According to you user_auth is MODEL or part of it. According to me - it is only a reference. The model is only the {list of transactions}. The reason is that real information is unaffected irrespective of whether a particular browser session should be allowed to display. According to me what remains persistent till it's functional value changes only that qualifies to considered as model. This is only my view.
    – Dipan Mehta
    Nov 1, 2011 at 19:35
  • If you see a session mechanism strictly as a mechanism that maintains state, your opinion may even be correct. But if sessions did nothing more than hold state references they wouldn't be so useful. Try to understand that I'm approaching sessions from their data storage perceptive, a session registry is an extremely common pattern in web development. Also I don't refer to anything as {list of transactions}, it's a term quite unknown to me and I'm having a hard time understanding what you mean by it. Could you please explain using some standard terminology? Also, every information is real.
    – yannis
    Nov 1, 2011 at 19:53
  • 1
    My problem is that you write stuff like correct MVC architecture but don't provide any references as to why your understanding of MVC is correct. Further more, there is no correct MVC architecture: MVC is a pattern and it's implementations can have myriad technical differences and still be "correct" (adhere to the pattern that is). Also a model is not a list of transactions or a list of anything, it's what it's definition in MVC says it is. Anything that works with data can be structured as a model, nuff said.
    – yannis
    Nov 1, 2011 at 21:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.