Базовый бизнес-класс: это плохо?

Question

Я хотел бы создать свой базовый бизнес-класс, что-то вроде EntityBase, чтобы иметь какое-то общее поведение, например, реализовать интерфейс для отслеживания изменений в объекте (IsNew, IsDirty) и в интерфейсе INotifyPropertyChanges.

Но многие люди говорят, что это плохая идея иметь базовый бизнес-класс и извлекать из него все ваши бизнес-объекты. Обычно они говорят, что плохо иметь код презентации в классе сущности. Но я думаю, что это просто теория. Что плохо на практике? Говорят: попробуйте сами. Обычно нет никаких аргументов.

Так что вы, ребята, думаете? Это хорошо или плохо? Если плохо, почему? Пожалуйста, постарайтесь быть практичным человеком, а не теоретическим.

Answer 1

Плохо. У нас это было в течение нескольких лет, и мы не смогли добавить в наш базовый класс, который был достаточно общим, чтобы он применялся ко всем унаследованным классам.

Answer 2

Многие люди подписываются на идею Single Responsibility Principle, в которой говорится, что класс должен иметь только одну область ответственности. Создавая отслеживание состояния, рендеринг и т. Д. В общий базовый класс, вы, безусловно, нарушите SRP. Если класс обрабатывает многие задачи, у него будет много причин для изменения.

Answer 3

Возможно, это не самое элегантное решение с точки зрения объектно-ориентированного дизайна, но если вы собираетесь использовать привязку данных, часто рекомендуется внедрять INotifyPropertyChanged в базовом классе. Таким образом, вы можете свести к минимуму нагрузку на его реализацию во всех своих сущностях.

В случае отслеживания изменений вы должны взглянуть на шаблон Unit of Work, если хотите отделить эту ответственность от своего базового класса, хотя очень часто наблюдается отслеживание изменений, реализованное по мере того, как вы указываете в приложениях .net, которые не Не полагайтесь на ORM.

Answer 4

Я не думаю, что обязательно иметь набор интерфейсов и базовых классов, реализующих эти интерфейсы, которые предоставляют некоторые общие функции, которые вы хотите в своих бизнес-сущностях, если ваши бизнес-сущности не обязаны извлекать из этих базовые классы. Это дает вам гибкость в вашей реализации, обеспечивая при этом удобство реализации.

Например, у меня есть интерфейс IValidatedEntity, который применяется к каждому бизнес-объекту, который я создаю. Это требует, чтобы бизнес-объект реализовал некоторые правила проверки. Тем не менее, мои объекты аудита создаются только внутренне, и я использую модульное тестирование, чтобы убедиться, что я не могу создать недопустимые объекты аудита, чтобы эти классы не реализовали интерфейс IValidatedEntity.

Большинство моих классов, которые принимают входные данные из Интернета И содержат строковые данные, полученные из класса XSSValidatedEntity (который реализует интерфейс IValidatedEntity), но обеспечивают проверку XSS с помощью парсера HTML, чтобы предотвратить инъекцию HTML в базу данных. Для большинства моих классов это отлично работает, но в тех случаях, когда я хочу разрешить ограниченный (безопасный) HTML, я, очевидно, не могу извлечь из этого класса.

Answer 5

То, что вы описываете, больше похоже на объект презентации, но IsDirty и IsNew также могут использоваться в модели домена. Прежде чем принимать решение о том, что включать в базовые объекты, вы должны иметь четкое представление о требованиях к бизнесу. Сосредоточив внимание на бизнес-объектах на мгновение, насколько статичными будут требования? У вас есть понимание всех ваших правил, которые определяют, как будут взаимодействовать объекты, и изменятся ли эти правила? Если они меняются, как часто?Это может оказаться для вас наиболее сложным.

Вы можете обнаружить, что в зависимости от приложения основная часть вашей работы должна исходить от реализации бизнес-процесса и, следовательно, архитектуры функциональности CRUD. будучи важным, не является фокусом ваших усилий. Другими словами, ваши бизнес-объекты будут поддерживать концепции бизнес-процесса, а не включать IsDirty. Затем ваш уровень доступа к данным может сосредоточиться на состоянии записей и определить, следует ли вставлять или обновлять данные.