Ответ 1
Репозиторий должен иметь единую ответственность - сохраняйте один вид объекта. Например. сотрудники. Если вам нужно удалить некоторые связанные записи из другого репозитория, это выглядит как бизнес-логика. Например.
Когда сотрудник уволен, мы должны удалить его журнал работы
И обычное место для бизнес-логики - это службы домена. Эта служба будет иметь как репозитории, так и всю работу:
staffService.Fire(employee)
Реализация будет выглядеть как
public class StaffService
{
private IEmployeeRepository employeeRepository;
private IWorkLogRepository workLogRepository;
private IUnitOfWorkFactory uowFactory;
// inject dependencies
public void Fire(Employee employee)
{
using(var uow = uowFactory.SartNew())
{
workLogRepository.DeleteByEmployee(employee.Id);
employeeRepository.Delete(employee.Id);
uow.Commit();
}
}
}
Итак, основные рекомендации
- попытайтесь сохранить свою бизнес-логику в одном месте, не распространяйте ее часть на пользовательский интерфейс, часть его на хранилища, часть на базу данных (иногда из-за проблем с производительностью вы должны делать некоторую логику на стороне базы данных, но это исключение)
- никогда не позволяйте репозиториям ссылаться на другие репозитории, репозиторий - очень низкоуровневый компонент вашего приложения с очень простыми обязанностями.
Вы можете задаться вопросом, что делать, если у вас есть сотрудник, и у него есть вложенный объект, который хранится в другой таблице базы данных. Если вы используете этот объект отдельно от сотрудника, то все как указано выше - вы должны иметь отдельный репозиторий и некоторый другой объект (услугу), который управляет обоими репозиториями. Но если вы не используете этот вложенный объект отдельно от сотрудника, тогда сотрудник является агрегированным корнем, и у вас должен быть только репозиторий сотрудников, который будет запрашивать обе таблицы внутри.