Какую функциональность встроить в бизнес-объекты?

Question

Как вы думаете, какую функциональность следует встроить в постоянный бизнес-объект как минимум?

Например:

• проверка
• способ сравнитьдругой объект того же типа
• возможность отмены (возможность отката изменений)

Answer 1

Функциональность, продиктованная доменом и бизнесом.

Чтение Дизайн, управляемый доменом .

Answer 2

Постоянный бизнес-объект должен состоять из следующего:

• Данные
• New
• Сохранить
• Удалить
• Сериализация
• Десериализация

Часто вы абстрагируете функциональность для извлечения их в репозиторий, который поддерживает:

• GetByID
• GETALL
• GetByXYZCriteria

Вы также можете обернуть этот тип функциональности в классы коллекций (например, BusinessObjectTypeCollection), однако существует много движений в направлении использования шаблона репозитория в дизайне, управляемом доменом, для предоставления этих типов средств доступа (например, InvoicingRepository.GetAllCustomers, InvoicingRepository.GetAllInvoices) .

Вы можете поместить бизнес-правила в «Создать», «Сохранить», «Обновить», «Удалить» ... но иногда у вас может быть внешний механизм бизнес-правил, которому вы передаете объекты.

Answer 3

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

Кроме того, бизнес-правила должны быть в бизнес-объектах.

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

Я не могу думать ни о чем другом, что требуется вообще.

Answer 4

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

Все постоянные платформы также включают в себя средства поиска, способы каскадного удаления ... сортировки ....

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