Where should the session object exist in MVC architecture?

Question

I've build my own MVC framework, but I'm still getting my head around a few things.

I have a class to handle session methods such as refreshing sessions, verifying sessions, starting sessions, closing sessions.

My question is where should I declare it in my MVC architecture?

I have an abstract base class, which is extended by the controller.
This base class then declares the model and view.

Should it go in the base class? If so how can I refer to session object methods from the model? Or should I aim to only trigger it from the controller?

I'm new to Object Orientated php as well which makes this more hard. My mind is boggling!!

Just as an aside: If you're still getting to grips with OOP, you might want to submit some of your code for peer-review, on codereview (another stack-exchange site). I've reviewed [a request class some time ago](http://codereview.stackexchange.com/questions/29469/critique-request-php-request-method-class), which might help you structure/improve on your code so far... — Elias Van Ootegem, Nov 13 '13 at 13:13
Session should be part of the model layer, as described [here](http://stackoverflow.com/a/16650437/727208) — tereško, Nov 18 '13 at 13:49

score 3 · Answer 1 · answered Nov 13 '13 at 12:43

The best way to think of problems involving OO is to consider the following simple questions:

Is your object a representation of something?
Is it actually going to modify other representations?
Is it purely there for display?

Answering "yes" to 1 and "no" to 2 usually (99% of the time) points to the role of a model. "no" to 1 and "yes" to 2 identifies a controller, while "no" to 1, 2, and "yes" to 3 implies a view.

Answering the following highlights inconsistencies or lack of separation:

Yes - yes - no - your model is not clearly separated
Yes - yes - yes - you effectively have an object trying to do everything
Yes - no - yes - your view and models are not separated

In your case, a session is a representation of a state that is held for a client. It therefore can only modify itself, and does not act on anything else. It is a model and is best represented as one.

You should ideally create a session storage controller/object/helper (depending on framework) to insert, recover and update session models, by the way. This is akin to a data provider.

I see, so if it is itself a form of model, then it should be declared from the base class then? So that it can be called from the controller in all cases required? — Amy Neville, Nov 13 '13 at 12:47
You might add that a Session class is actually related to other Request objects one might have, and that, in general, they should be made available to the controller from the get-go. Often there is such a thing as a dispatcher, kernel or bootstrapper which creates these instances, and passes them on to the controller — Elias Van Ootegem, Nov 13 '13 at 12:56

score 3 · Accepted Answer · answered Nov 13 '13 at 13:08

The request objects are best thought of, or at least written as, being part of the model layer, but because you're writing for the web, Request objects are part of the core of your Framework.
But to clarify:

Effectively, a Session class is a data model, and one could argue that it's part of a bigger subset of request models. Remember, MVC doesn't imply that each request requires a Controller, View and "A Model".
The Model bit, especially, is a layer. It can contain services, data models, an ORM, helpers and what have you...

That said, All things deal with the request should be at the ready in the controller. That's how most FW's work. Check the symfony workflow of a request, and note how far apart the controller and the request are.
This graph, though it deals with the ZendFW cycle, shows the special status of the request object(s) even more clearly:

ZFW request cycle

The server receives the request, the framework kicks in and pours the request into the corresponding objects.
Then, in the code that resolves the request to a given controller, and controller action, I'd pass the required request objects to the controller's constructor.
A basic schematic would be:

Request ===> index.php (startup script)
         ||
         || some basic checks, create objects
         ||
         |_==> create base controller
                       ||
                       ||
                       |_==> pass request to constructor, or starter method
                             Do more specific/targetted checks
                                   ||
                                   ||
                                   \/
                        controller has access to request through base controller
                               and can pass this through to the model layer

So, in resuming, and because I believe repetition works: The request objects are best thought of, or at least written as, being part of the model layer, but because you're writing for the web, Request objects are part of the core of your Framework.

I see! So essentially my other layers such as errors, sessions, etc are also model(s). Essentially an MVC has many models to handle different layers! Wow ty :) — Amy Neville, Nov 13 '13 at 13:12
@AmyNeville: Indeed: the Session object is a sub-module of the Request module. The controller implementation of your framework is basically a module, that offers an interface which ppl can use to write the _actual_ controllers. The Request object is far to important to leave up to users to implement, but you _can_ offer an interface for plugins to manage the routing, for example... when writing your own FW, which is a very educational thing to do, looking into how existing FW's work is essential, IMO — Elias Van Ootegem, Nov 13 '13 at 13:17

score -2 · Answer 3 · answered Nov 13 '13 at 12:41

-2

The controller should handle this.

When you will need to set variables, refresh thing inthe session, the controller will do it from the results of your backend functions. That way you do not have to import this session class in every service, backend or utils class and it will always be done in the same way at the same level of coding.

answered Nov 13 '13 at 12:41

Damounet

96
2
9

This leads to poor separation of concerns, and is especially visible the moment you have to switch session providers (like a move from the internal PHP sessions to redis or otherwise). Creating a separate data store does not prevent you from referencing it in your objects. – Sébastien Renauld Nov 13 '13 at 12:44
There's a worrying undertone in your answer: assuming that, in the context of a webapp something like the Session should be dealt with in the controller (written by a user of the FW), means that something as vital/crucial as the request isn't being dealt with consistently. One user might opt to write a `Session` class, whereas the other might just in-line everything usign `session_destroy` and the like... That's madness. – Elias Van Ootegem Nov 13 '13 at 13:31

Where should the session object exist in MVC architecture?

3 Answers3