A BaseModel in PHP MVC, good or bad?

Question

I'm writing my own MVC framework in PHP, just for learning purposes. It wasn't really hard to have a router/dispatcher class to call the right controller/action etc.

But now i'm at the part where i'm going to use models. Or actually, the model layer. But there's something that confuses me.

Alot of other MVC frameworks have a 'BaseModel'. I've read that this is actually bad practise, because the "Model" shouldn't be seen as another class. But as a real 'layer', which can contain things like the 'mapper' pattern or 'repository' pattern etc.

But to be honest, i don't see any advantages in that. To me, a 'BaseModel' class seems to be the fastest way to go, with the same results.

I can simply do something like:

class User extends BaseModel
{
    // the GetUserBy* could easily be something that's handled by the
    // BaseModel class, like in the Repo pattern.

    public function getUserByName ( $name )
    {
        // no error handling of any kind, just for simplicity
        return $this->db->exec("SELECT * FROM users WHERE name='".$name."'");
    }

    // $data = array
    public function saveUser ( $data )
    {
        // Make sure no extra fields are added to the array
        $user = array ( 'name' => $data['name'],
                        'address' => $data['address']);

        $this->db->autoSave ( $user );
    }
}

But if i'd go for a repository pattern then i have to create the following: Repositories Entities DAO

Entities have Aggregates to other repositories. So basically i'm manually writing out my entire database scheme to objects...

In the end, what's the difference??? Except that i probably could have saved alot of time by simply using a BaseModel class...

But why is it still considered to be a bad thing then?? It's not that the repo pattern decouples my application more then i'm doing now. Because to me, those patterns mentioned above seem to be highly overrated. It probably would only work in an application that has a shared state; Save objects locally (in the repository) and commit them later on.

That's why i think no one can really answer this...

But i'm still hoping to see a decent answer that makes me go: "ahhhh... What was i thinking....". But if not, then i'm sure about my case that the BaseModel isn't a bad thing at all and that most bloggers are just a bunch of sheeps :-)

Answer 1

It's not that the repo pattern decouples my application more then i'm doing now

Your application is tightly coupled to SQL database components (which are, in effect, acting as your mapper). However, despite this, your design is much more like a Repository than an Active Record approach (which is likely what most of these bloggers you refer to are griping about).

Active records encapsulate not only the data, but also the database access:

$user = new User();
$user->setUsername('jane');
$user->setEmail('jane@foo.bar');
$user->save();

It's nicer to have the record objects be unaware of the persistence layer (separation of concerns). Your "base" does just that by returning arrays of user data and when those arrays are modified, they must be passed back to the user "base" for saving. You could change your naming to:

class UserRepo extends BaseRepo
{
    // user-specific repo code...
}

$userRepo = $this->getRepo('User');
$user = $userRepo->getUserByName('jane');
$user['email'] = 'jane@new.email';
$userRepo->save($user);

There's nothing wrong with having a base repo.

Answer 2

If you are trying to learn good MVC practices from PHP frameworks, then you are doing it wrong. Even the best frameworks in PHP are riddled with design mistakes and flaws.

The frameworks what have "BaseModel" usually are implementing some sort of ORM. And the most popular pattern here is ActiveRecord. It is nice for simple tables, with no relations to others (basically - glorified getters/setters). But starts to break down, when dealing with more complex structures and queries. Usually causing extensive technical debt.

The other reason, why this approach causes problem,s is that your "model" in this case has too may responsibilities. Your business logic is tightly bound to the storage, and storage is welded to the logic. As the application grows, such "models" will accumulate hacks.

And no, the "bunch of bloggers" are not sheep. They just have read books about application architecture and object oriented programming. When was last time you read a book on this subject ?

Answer 3

The Model class should be abstract, only defining methods without implementing them. As for your User model, you can easily write an interface GettingUsers which would have all those functions, and implement that on the User model.

Answer 4

I wouldn't use a base model at all as most of your models won't have a uniform interface that they should conform to. You could create a base class for a number of different types of models (which is just basic object oriented programming) if you wanted to.

Overall, I believe the models are supposed to be the "loose" components that you wire together with a controller and display with one or more views. They can't really have a uniform interface because they all would do different things: some may not even talk to a persistence store, some may not be persistent, and/or some may be composed of other models.