Разделение интерфейсов и реализация

Question

Что вы думаете о разделении интерфейса (1.assembly) и его реализации (2.assembly) с точки зрения сборки (или модуля)?

Таким образом, мы можем использовать некоторый контейнер IoC для разработки более развязанного дизайна. Скажем, у нас есть сборка «A», которая содержит только интерфейсы.Затем у нас есть сборка «B», которая ссылается на «A» и реализует эти интерфейсы. Она зависит только от «A».

В сборке «C» мы можем использовать контейнер IoC для создания объектов«A» с использованием внедрения зависимостей объектов из «B».Таким образом, «B» и «C» совершенно не осознают (не зависят) самих себя.

Answer 1

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

Если нет, и один и тот же проект будет использовать одни и те же интерфейсы (но несколько раз), нет необходимости их разделять. Контейнер IOC может просто использовать интерфейсы в одной сборке.

Рассмотрим:

Assembly 1:
    IFoo

Assembly 2:
    IOC Container
    ConcreteFooOne : IFoo

Assembly 3:
    IOC Container
    ConcreteFooTwo : IFoo

_{Обратите внимание, что в этом случае контейнер IOC в каждой из сборок будет отвечать за каждый экземпляр IFoo и присвоение ему правильного ConcreteFoo.}

Это имеет смысл иметь отдельную сборку для интерфейсов. Каждая из других зависимых сборок (1 и 2) может использовать интерфейс IFoo. С другой стороны, если ConcreteFooOne и ConcreteFooTwo, где оба в одной сборке, не будет необходимости разделять интерфейс IFoo. Контейнер IOC все еще может использовать « plug and play », переключая конкретные экземпляры при необходимости.

Update

Судя по вашему комментарию, вы, похоже, беспокоитесь о привязке контейнера IOC к сборке. Это не проблема, и разделение контейнера на отдельную сборку не является обязательным требованием. Во всяком случае, я бы отнес это к запаху кода, не говоря уже о бессмысленном действии.