Является ли использование корневого персистентного класса или базового персистентного объекта запахом архитектуры?

Question

Одна из основных претензий сообщества Alt.Net к Microsoft Entity Framework заключается в том, что она заставляет вас использовать базовый постоянный объект для всего, что хранится в базе данных. У меня есть два вопроса, связанных с этим:

1. Допустимо ли в качестве основы для доменных объектов в вашем приложении иметь «Root Persistent Class» или это запах архитектуры?

2. Если вы чувствуете, что это нормально для вас, чтобы иметь один в вашем приложении, то также нормально для платформы ORM, чтобы заставить вас использовать один? Есть ли причины избегать рамок, которые заставляют вас это делать?

В течение некоторого времени я использовал абстрактный базовый объект в качестве корня всех моих скоропортящихся классов. Это облегчает работу по дому.

Answer 1

Мне кажется, что все в порядке, если предположить, что контекст таков, что он

1. остается в стороне
2. не добавляет функции, которые не используются вне области сущности
3. не привязывает вас к какому-либо конкретному ORM (что-то вроде # 2)

Так что, если базовый класс используется для описания, например, идентификатора и значения равенства (поскольку объекты считаются равными, если они имеют одинаковый идентификатор), то это нормально. Однако, когда он начинает описывать информацию, ориентированную на базу данных (например, таблицы, столбцы, состояние объекта и т. Д.), Тогда да, я думаю, что она начинает пахнуть.

Answer 2

Для приложений с низким или средним уровнем сложности использование базового персистентного объекта действительно может повысить производительность разработки.

Тем не менее, это ограничивает ваш код и ограничивает возможности проектирования, поскольку ваше приложение становится все более сложным. Очевидно, вы используете свой базовый класс с самого начала, что важно в C # и Java. Это также способствует плохому разделению проблем.

Я бы сказал, что самое важное при рассмотрении любого ORM - это задать эти вопросы (из статьи Джереми Миллера Модель единицы работы и невежество в постоянстве ):

• Может ли бизнес-логика работать независимо от базы данных?
• Могу ли я разработать свою модель домена независимо от модели базы данных?
• Как стратегия постоянства влияет на мою бизнес-логику?

Answer 3

Если вы не используете объекты переноса данных (DTO) для персистентности и не используете эту модель, то, как мне показалось, наличие корневого объекта для персистентных классов значительно уменьшает повторение кода и повышает производительность труда разработчика. И даже при использовании DTO, я думаю, что это может быть полезно, хотя я редко использую DTO, поэтому не могу говорить из опыта.

Я бы не считал это запахом кода по следующим причинам:

1. Увеличение производительности разработчиков.
2. Объединяет постоянный код в одном классе.
3. Легко перейти на другую платформу, которая реализует ту же методологию (нужно только изменить наследование всех ваших бизнес-классов и обновить проверки исходного корневого класса).

Редактировать: Встроенный ответ statichippo, я согласен с его мнением об этом базовом классе, включая информацию о базовых механизмах хранения данных (таких как имена таблиц / столбцов, тип базы данных и т. Д.).