CODEWITHSUNDEEP
phpsessionmodel-view-controller
Amy Neville
Amy Neville

Reputation: 10621

Where should the session object exist in MVC architecture?

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?

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!!

Upvotes: 2

Views: 1482

Answers (3)

Elias Van Ootegem
Elias Van Ootegem

Reputation: 76423

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.

Upvotes: 3

Sébastien Renauld
Sébastien Renauld

Reputation: 19672

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

  1. Is your object a representation of something?
  2. Is it actually going to modify other representations?
  3. 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:

  1. Yes - yes - no - your model is not clearly separated
  2. Yes - yes - yes - you effectively have an object trying to do everything
  3. 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.

Upvotes: 3

Damounet
Damounet

Reputation: 120

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.

Upvotes: -2

Related Questions