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!!
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:
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.
The best way to think of problems involving OO is to consider the following simple questions:
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:
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.
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.