Правильно ли иметь ссылки на хранилища на фасадах? - PullRequest
Новая
       1

Правильно ли иметь ссылки на хранилища на фасадах?

1 голос
/ 10 ноября 2010

Или я всегда должен получать свои сущности с помощью методов обслуживания?

Спасибо

1 Ответ

2 голосов
/ 10 ноября 2010

Большую часть времени я стараюсь максимально разделить свои слои. Обычно мои услуги действуют как фасады бизнес-логики. В рамках бизнес-логики я использую DI-контейнер, например, Unity, для разрешения своих репозиториев ...

Пример: 

IUnityContainer container = IoCManager.Container;
using (var repository = container.Resolve<IRepository<Token>>())
{
    return repository.Eagerly(f => f.Fetch<TokenSetting>(t => t.Settings))
                     .Where(t => t.Value == tokenGuid && t.Expired == null)
                     .FirstOrDefault();
}

Моя бизнес-логика теперь не содержит зависимостей от уровня моей инфраструктуры (репозитории). Для отличной реализации репозитория взгляните на NCommon. Ритеш Рао написал несколько замечательных примеров использования шаблонов для DDD.

Субъективно, неправильно ли ссылаться на ваши репозитории. Я думаю, что пуристы DDD скажут вам, что, скорее всего, так и есть. «Сколько SoC вы пытаетесь достичь» - это реальный вопрос. Обычно лучше всего стремиться к высокой сплоченности через слабую связь, но иногда это может быть излишним.

Надеюсь, это поможет.

[Изменено]

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

Посмотрите на Мартин Фаулер - Разделенный шаблон интерфейса . В моем примере выше я зависел от интерфейса. Контейнер DI разрешает фактическую реализацию моего конкретного класса репозитория. Вот пример диаграммы DDD, которую я дорабатывал, когда учусь. alt text

...