Инверсия зависимостей - владелец интерфейсов? - PullRequest
Новая
       2

Инверсия зависимостей - владелец интерфейсов?

0 голосов
/ 11 января 2011

Я начинаю с ASP.NET MVC и пытаюсь изучить DI и инверсию зависимостей одновременно.Я настраиваюсь в проекте MVC, где контроллеры и представления находятся в одной сборке, и у меня также есть несколько дополнительных сборок для моделей домена и сервисов, которые соответствуют большей части реальной бизнес-логики.

План состоит в том, чтобывсе мои сервисы реализуют интерфейсы.Контроллеры, которые вызывают сервисы, получают к ним доступ через эти интерфейсы.Инстанцирование выполняется с использованием инфраструктуры Ninject DI.

Теперь актуальный вопрос;кто "владеет" интерфейсами?Из моего понимания инверсии зависимостей сервисные интерфейсы будут принадлежать контроллерам и, следовательно, находиться в этой сборке.

Ответы [ 3 ]

0 голосов
/ 11 января 2011

Интерфейсы к службам (обычно предоставляют данные и реализованы в виде WCF) должны находиться в отдельной DLL, а MVC будет иметь ссылку на.

Итак, вот типичное (и базовое) разбиение классов и интерфейсов на проекты (и сборки):

  • Общее
  • Сущность (общее обозначение)
  • Сервисный интерфейс (ссылка Common и Entity)
  • Внедрение услуг (см. Все выше)
  • Презентация (ссылки на все вышеперечисленное, кроме реализации) и имеет протоки WCF, просмотр определенной логики
  • Проект MVC (ссылки на все выше, но реализация)
0 голосов
/ 11 января 2011

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

Физическое их разделение создает головные боли, которые могут быть ненужными - я рекомендую не использовать несколько сборок без уважительной причины.

0 голосов
/ 11 января 2011

Интерфейсы должны быть видны разработчикам.Реализация может быть видна потребителям.Если вы хотите отделить реализацию от интерфейса, чтобы их можно было развернуть отдельно, то интерфейсы должны находиться в их собственной сборке.

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

...