Должен ли репозиторий или бизнес-уровень обновлять все таблицы?

В моем проекте у меня есть таблица «Клиенты» с тремя внешними ключами к таблице «Адреса». Один для MainAddress, один для BillingAddress и один для ShippingAddress.

Я использую шаблон единицы работы и репозитория с CustomerRepository и AddressRepository.

Иногда мне нужно будет работать с адресами самостоятельно, но в большинстве случаев они будут частью объекта домена Customers.

Мой вопрос - это вопрос о передовом опыте проектирования. Должен ли уровень бизнес-логики отвечать за вызов как CustomerRepository, так и AddressRepository для добавления/обновления, или же CustomerRepository должен быть достаточно умным, чтобы добавлять/обновлять адреса, чтобы BLL нужно было вызывать только «AddCustomer» или «EditCustomer» и все таблицы адресов автоматически добавляются/обновляются?


repository-pattern design-patterns business-logic
person Scottie    schedule 27.01.2012    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я бы позволил CustomerRepository также обрабатывать обновление адресов. Я предполагаю, что вы используете объектную модель, в которой объект клиента имеет общий набор адресов, используя отношение «имеет» (т. е. клиент имеет адреса). Если вы используете ORM под капотом вашего репозитория, он все равно будет обрабатывать обновление этого объекта и его отношений. Я не вижу смысла в том, чтобы каждый репозиторий обрабатывал отдельные объекты этого отношения или в вашей бизнес-логике, требующей обработки обновлений этого отношения. Я бы использовал AddressRepository только при работе напрямую с адресами. Это мой совет для этого примера простого отношения «имеет». Будут времена с более сложными отношениями, когда вы захотите, чтобы бизнес-логика обрабатывала это для вас, а не репозиторий. Примером может быть ситуация, когда объекты распределены по разным хранилищам данных.

person Kevin Junghans    schedule 27.01.2012
comment
Да, я использую структуру сущностей в качестве ORM. Спасибо за помощь! - person Scottie; 27.01.2012