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

Question

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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