Objective oriented design in a PHP MVC Framework

Question

Traditionally in a MVC framework (Such as CodeIgniter or Kohana) I create controllers as I create different pages. There will be a login controller, a home controller and so on. But recently I learned more about objective oriented programming and want to start using it. And even though the framework uses classes, it's not the same principle as an object.

Yes. The login controller is as an object. But where am I supposed to write my "User" class for example? Do I write them in a library and import them when needed? What is the proper way of doing this, if there even is any.

I'm just puzzled on how I can do this right.

Answer 1

_<rant>

_{If you start out with frameworks that are either direct Rails clones or heavily influenced by Rails architecture, you are not really implementing MVC. Ruby on Rails framework was originally intended to be a purely rapid prototyping framework, which means that they sacrificed most of MVC concepts on "The Altar of Scaffolding".}

_{Rails-based PHP frameworks replace fully functional views with templates, model layer with some collection of active record instance and for the "controller" to deal with all the presentation and application logic.}

_</rant>

The bases of MVC design pattern is the separation between business logic (contained in model layer) and user interface (managed by presentation layer). These two layers each contains different groups of structure.

The User is not a model. There are no "models" in modern MVC. Instead your User instance is a domain object. Also, it should not be directly exposed to the controllers or other presentation layer structures.

The interaction between presentation layer and model layer should be performed by services. Services in model layer are structures, which are responsible for handling the interaction between domain objects and storage abstractions (either data mappers directly or via repositories and/or units of work).

namespace Controller;

class Authentication
{
    // .... snip
    public function postLogin( $request )
    {
        $service = $this->serviceFactory->create('Recognition');
        $service->authenticate( $request->getParameter('username'),
                                $request->getParameter('password') );
    }
    // .... snip
}

In this case the User instance is somewhere inside the recognition service, which is there to deal with different business-logic aspects of user authentication. And do not confuse it with authorization. For authorization in MVC context there is a bit different recommended approach.

_{P.S.: if you are just now starting to really delve into OOP, you might find this list useful in your research.}

my two cents

Answer 2

It is better to write your User class as a library since it is not a controller(assumption) and you should not have direct access to the User class through the URL. So the best practice is to write a Class if you want it to be object oriented. Or you can create a helper file if you want to have static functions.

Answer 3

I think it's too individual. Really depends on what kind of application is built. Let's think out of the CodeIgniter or Kohana, but for your individual framework, with individual application.

If you have simple login system, where the user is nothing but a Name and an ID, and all the interactions are between the other stages of the application, instead interactions between the users, your User Class which only contains information about the user (simple queries to the db which retrieves certain information from users table), can be a helper.

But in some applications (platforms in this case), the user might be an equal to any other object in it.

For example building a Forum-like application, you might want to have Warn level, Reputation, various logs of user actions, etc.

Also the user is an equal object like a 'topic', which also have for example likes/dislikes, priority, etc.

In this case you build a model and a controller for the user. For example in your Model you will have methods like

createUser(), getUser(), getUserWarnActions(), updateUserActions(), logUserActionChange(), etc, etc.

All of that methods, will be in a class called i.e. UserModel which extends the Model main class

where for example UserActions are the warn level, the email change, username change, reputation change.

In your controller, you might want to have

updateWarnLevel() => which interracts with updateUserActions(), tells the model it's action = warn level, and updates it, by the given value

so these methods will be in a class i.e. called UserController which extends the Controller main class

But at all it really depends how you look on your User class as. According to me it will be bad practice to have Controller/Model called Warn level, since it's a part of another abstraction, but not individual one.

To assume which is a child or a parent, I would try to make a structure, like a db one, and then create models/controllers/helpers.

If you have the following database tables:

• users
• user_reputation
• user_warnlevels
• topics
• topic_votes
• warn_levels // contains i.e. id | level | something_which_depends_on_the_level

It definately means that Users and Topics would be Models/Controllers in your application, where warn_levels won't be, since they are separate table only because they have some logic, but they are no parent table, only child one