Design problems of ActiveRecord for large application

Admin 1
Viewed 970

In most of the frameworks you have model classes that represents row in the database.

For example php code:

class User extends Model {}

I'm giving Laravel eloquent example but this is true for most php frameworks.

Then you add the relationships in the class:

public function pictures()
{
    return $this->hasMany('App\Picture');
}

Then you add some methods like this:

public function deleteComments()
{
    // delete comments code here
}

My first question is: Is this good design architecture because after years when the project becomes large you will have many relationships (pictures, comments, posts, subscriptions, etc connected to the user). The class could become 10k lines of code or so.

In that case, the class will become very large and hard to maintain. Also the Single Responsible Principle maybe is violated because you have too many methods in one class.

Also if I want to use the class it in another app I cannot, simply because I'll have to pull also the pictures, comments and etc in the second application(website).

If I make other classes like "UserPictures", "UserPictureDeleter" the code will get more complicated.

So is this good practice and if not do you have any suggestions on how to make the code not bloated with so many methods but easy to use. Do you agree that all these methods belong to the User class?

eloquent laravel oop design-patterns php
4 Answers

Laravel and some another framework provide Active Record conception in their base classes of model. The main idea of Active Record is a representation of table row as an object that includes data of a row and methods of work with databases.

Using of Active Record pattern is fully justified in small simple applications because this pattern gives an ability to fast develop your application. But if your application has a lot of code and difficult business logic, Active Record will make many problems in the architecture of your application. Active Record can make the following problems:

  • violation of the Single Responsibility Principle that makes bloated code. Active Record always violates this principle, because it always has two responsibility: it implements business logic and methods of database work
  • violation of low coupling principle (GRASP) that makes code reuse more difficult
  • сreation of qualified abstraction is difficult if you use Active Record pattern

The solution to those problems is using of OOP abstractions instead of using of table rows abstractions. For example, you can use Domain Model and Domain-driven design. This approach is better than Active Record pattern for large applications.

Unfortunately, those concepts are too large-volume for explanation in this post, but you can read "Domain Driven Design" by Eric Evans. It is a good book about application design. Also, you can find many articles about those concepts in google. For example Building a Domain Model, Implementing Domain-Driven Design in PHP (Laravel)

user_102379500
user_25055150

The class could become 10k lines of code or so

Each relationship function is 2-4 lines of code so unless you have 2500-5000 relationships, this class is not going to be 10k lines of code. If you do, you already have bad database design.

Also the Single Responsible Principle maybe is violated because you have too many methods in one class.

Nowhere does the SRP state that you cant have too many methods in one class. It states that a class should have only a single responsibility/reason to exist.

Also if I want to use the class it in another app I cannot, simply because I'll have to pull also the pictures, comments and etc in the second application(website).

This class is a Model class. Its responsibility is to represent one database table. If you have the same table structure in other apps, then yes, you should pull in this class and you would need to pull in pictures, comments, etc. as well since you have the same table structure. If not, you shouldn't pull it in. I don't see any problem here.

user_73779840

Consider the following talk from Adam Wathan. He addresses an issue in naming, which leads to bloating of classes. If you consider his methodology of naming methods and shifting the responsibilities, you'll end up with smaller classes and easier to read code.

Besides don't let yourself get indoctrinated by some rules and 'laws' that exist in programming. If you need a class that is 10k lines, but it's readable then go for it.

user_79337100
Related