BaseModel in PHP MVC, good or bad?

Question

I am writing my own MVC framework in PHP, for educational purposes only. It was actually not easy for the router / dispatcher class to invoke the correct controller / action, etc.

But now I'm in the part where I will use the models. Or actually, a model layer. But there is something bothering me.

Other MVC structures have a "BaseModel". I read that this is actually bad practice, because the "Model" should not be considered as another class. But like a real “layer” that can contain things like the “mapper” or “repository” template, etc.

But honestly, I do not see any advantages in this. For me, the BaseModel class seems to be the fastest way with the same results.

I can just do something like:

class User extends BaseModel { // the GetUserBy* could easily be something that 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 went to the repository template, then I need to create the following: Repositories DAO legal entities

Entities have Aggregates with other repositories. So basically I manually write out the whole database schema for objects ...

After all, what's the difference ??? Except that I could probably save a lot of time just using the BaseModel class ...

But why is it still considered bad? It is not that the repo template separates my application more than I do now. Because for me, these patterns mentioned above seem very overpriced. It probably only works in an application that has a common state; Save objects locally (in the repository) and transfer them later.

That is why I think that no one can really answer this question ...

But I still hope to see a worthy answer that will make me go: "ahhhh ... What did I think ...". But if not, then I'm sure in my case that BaseModel is not bad at all, and that most bloggers are just a bunch of sheep :-)

Answer 1

It is not that the repo template separates my application more than I do now

Your application is closely connected with the components of the SQL database (which, in essence, act like your cartographer). However, despite this, your design is much more similar to Repository than Active Record (which is probably due to what most of these bloggers you name).

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

 $user = new User(); $user->setUsername('jane'); $user->setEmail(' [e-mail] '); $user->save(); 

It is best that the recording objects are not aware of a constant level (separation of problems). Your "base" does just that, returning arrays of user data and when these arrays are modified, they must be returned to the user "base" for storage. You can change your name to:

 class UserRepo extends BaseRepo { // user-specific repo code... } $userRepo = $this->getRepo('User'); $user = $userRepo->getUserByName('jane'); $user['email'] = ' [e-mail] '; $userRepo->save($user); 

There is nothing wrong with having a basic repo.

Answer 2

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

Structures that have a "BaseModel" typically implement some kind of ORM. And the most popular template here is ActiveRecord. This is good for simple tables, without any relationship with others (mostly renowned getters / setters). But it begins to collapse when working with more complex structures and queries. It usually causes extensive technical debt .

Another reason why this approach causes a problem is because your “model” in this case can also be held responsible. Your business logic is closely related to the repository, and the repository is welded to the logic. As the application grows, such “models” will accumulate hacks.

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

Answer 3

The Model class should be abstract, only defining methods without their implementation. As for your User model, you can easily write the GettingUsers interface, which will have all these functions, and implement it in the User model.

Answer 4

I would not use the base model at all, since most of your models will not have a uniform interface, which they should correspond to. You could create a base class for several different types of models (this is just basic object-oriented programming) if you wanted to.

In general, I believe that models should be “free” components that you connect with the controller and display with one or more views. They cannot have a single interface, because they will all do different things: some may not even talk to the persistence repository, some may not be permanent, and / or some of them may consist of other models.