Замок Виндзор (или любой каркас IoC) и внутренние зависимости

Question

У меня возникли проблемы с тем, чтобы моя голова использовалась с использованием инъекции зависимостей с внутренними типами. Хотя я уже несколько лет использую Castle Windsor, мне никогда не приходилось слишком много думать о видимости, поэтому все, как правило, стало публичным (отчасти для того, чтобы держать Виндзора счастливым и отчасти облегчить насмешку над модульными тестами) , Однако теперь у меня есть требование разработать API.

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

Скажем, мой уровень API предоставляет метод GetCustomer(). Это возвращает класс Customer, который предоставляет метод SendEmail(), который использует класс MailService для достижения электронной почты.

Я хочу ввести MailService в Клиент, но я не хочу, чтобы MailService был доступен для потребителей API. Я считаю, что он не может быть внутренним, поскольку вы не можете передать внутренний тип публичному конструктору. Поэтому имеет смысл сделать внутренний клиент Ctr (как только BLL должен их создать), но Windsor жалуется, потому что зарегистрированные типы должны иметь открытый ctr.

Я чувствую, что мне не хватает чего-то фундаментального со всем этим. Как я мог бы спроектировать что-то подобное? Я предполагаю, что одно из решений - это интерфейсы, но почему-то не кажется правильным создание интерфейса для каждого внутреннего типа, когда будет (как правило) только одна реализация.

Answer 1

Я считаю, что он не может быть внутренним, поскольку вы не можете передать внутренний тип публичному конструктору.

C# не будет компилировать ваш класс, если публичный конструктор зависит от внутреннего типа, что очевидно. Но на самом деле вы можете передать внутреннюю реализацию публичному конструктору, если зависит от конструктора, и он также является общедоступным.

Поэтому имеет смысл сделать Заказчик Ctr внутренного

Это не причина, чтобы сделать конструктор внутренним, так как это будет работать нормально, но если вы строите многоразовые библиотеки, делая внутренние конструкторы очень эффективными, поскольку, как только вы опубликовали свою библиотеку, изменение публичного конструктора является нарушением изменений. Поэтому сделать его внутренним - это хороший способ, позволяющий библиотеке меняться и расти в будущем.

но Виндзор жалуется, потому что зарегистрированные типы должны иметь открытый ctr.

Большинство библиотек DI позволяют переопределить поведение разрешения конструктора по умолчанию, так как does Замок Виндзор.

Поскольку вы создаете библиотеку многократного использования, я настоятельно рекомендую вам прочитать статью Mark Seemann's DI Friendly Library.