Проблемы проектирования ActiveRecord для больших приложений

Question

В большинстве фреймворков у вас есть классы моделей, которые представляют строки в базе данных.

Например, php-код:

class User extends Model {}

Я приведу красноречивый пример Laravel, но это правдадля большинства php-фреймворков.

Затем вы добавляете отношения в классе:

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

Затем вы добавляете несколько методов, подобных этому:

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

Мой первый вопросЭто хорошая архитектура дизайна, потому что после нескольких лет, когда проект станет большим, у вас будет много связей (фотографии, комментарии, публикации, подписки и т. Д., Связанные с пользователем).Класс может превратиться в 10 тысяч строк кода или около того.

В этом случае класс станет очень большим и сложным в обслуживании.Также может быть нарушен Единый ответственный принцип, потому что у вас слишком много методов в одном классе.

Также, если я хочу использовать класс, то это невозможно в другом приложении, просто потому, что мне придется также тянуть картинки, комментарии и т. д. во втором приложении (веб-сайте).

Если я создам другие классы, такие как "UserPictures", "UserPictureDeleter", код станет более сложным.

Так жеэто хорошая практика, и если нет, у вас есть какие-либо предложения о том, как сделать код не раздутым с таким количеством методов, но простым в использовании.Согласны ли вы с тем, что все эти методы относятся к классу User?

Answer 1

Рассмотрим следующий разговор от Адама Ватана.Он решает проблему именования, которая приводит к вздутию живота.Если вы рассмотрите его методологию именования методов и перераспределения обязанностей, вы получите меньшие классы и более легкий для чтения код.

Кроме того, не позволяйте себе внушать некоторые существующие правила и «законы»в программировании.Если вам нужен класс, содержащий 10 тыс. Строк, но он читабелен, сделайте это.

Answer 2

Вы можете улучшить свою модель с помощью интерфейсов. Если вам нужен один класс для наследования определенного поведения, общего с другим, разработав интерфейс, вам нужен новый класс для реализации только интерфейса.

Межфазное программирование

кодирование для преобразования в PHP

Answer 3

Класс может стать 10 тыс. Строк кода или около того

Каждая функция отношения состоит из 2-4 строк кода, поэтому, если у вас нет 2500-5000 отношений, этот класс не собираетсябыть 10 тыс. строк кода.Если у вас есть, у вас уже есть плохой дизайн базы данных.

Также может быть нарушен Единый ответственный принцип, потому что у вас слишком много методов в одном классе.

Нигде не работаетSRP заявляет, что вы не можете иметь слишком много методов в одном классе.В нем говорится, что класс должен иметь только одну ответственность / причину существования.

Также, если я хочу использовать класс в другом приложении, я не могу, просто потому, что мне придется тянуть такжекартинки, комментарии и т. д. во втором приложении (веб-сайт).

Этот класс является классом Model.Его обязанность - представлять одну таблицу базы данных.Если у вас такая же структура таблиц в других приложениях, тогда да, вы должны использовать этот класс, а также вам нужно добавить рисунки, комментарии и т. Д., Поскольку у вас такая же структура таблиц.Если нет, то не стоит его втягивать. Здесь я не вижу никаких проблем.

Answer 4

Laravel и некоторые другие фреймворки обеспечивают концепцию Active Record в их базовых классах модели. Основная идея Active Record - представление строки таблицы в виде объекта, включающего данные строки и методы работы с базами данных.

Использование шаблона Active Record полностью оправдано в небольших простых приложениях, поскольку этот шаблон дает возможность быстро разрабатывать ваше приложение. Но если в вашем приложении много кода и сложной бизнес-логики, Active Record создаст много проблем в архитектуре вашего приложения. Active Record может создавать следующие проблемы:

• нарушение принципа единой ответственности, который создает вздутый код. Active Record всегда нарушает этот принцип, потому что у него всегда есть две обязанности: реализует бизнес-логику и методы работы с базой данных
• нарушение принципа низкой связи (GRASP), что затрудняет повторное использование кода
• создание квалифицированной абстракции затруднено, если вы используете шаблон Active Record

Решением этих проблем является использование абстракций ООП вместо абстракций строк таблицы. Например, вы можете использовать Доменная модель и Домен-управляемый дизайн . Этот подход лучше, чем шаблон Active Record для больших приложений.

К сожалению, эти концепции слишком объемны для объяснения в этом посте, но вы можете прочитать «Проект, управляемый доменом» Эрика Эванса. Это хорошая книга о дизайне приложений. Кроме того, вы можете найти много статей об этих концепциях в Google. Например, Построение доменной модели , Реализация доменного дизайна в PHP (Laravel)