В многоуровневой архитектуре можно ли ссылаться на соседние слои?

Question

Если у меня есть приложение, которое состоит из нескольких слоев, определенных как несколько проектов в решении, нормально ли это, чтобы слой ссылался на слой непосредственно над / под ним? Или следует использовать инъекцию зависимостей для устранения этой необходимости?

Я опираюсь на более конкретные вопросы, которые я задавал здесь , но я хотел бы получить более общий совет.

Как бы я настроил такой проект в VS2010? Нужен ли мне третий проект для размещения DI? (Я использую Ninject)

РЕДАКТИРОВАТЬ: пример

Вот пример моих двух слоев. Первый уровень имеет интерфейс IUnitOfWork, а второй уровень имеет класс, который реализует указанный интерфейс. При такой настройке проект не будет построен, если слой 2 не имеет ссылок на слой 1. Как можно избежать этого? Или мне даже не стоит беспокоиться о ссылках и оставить их в покое, поскольку слои соседствуют друг с другом?

Слой 1

public interface IUnitOfWork
{
    void Save();

}

Слой 2

 public DataContext : IUnitOfWork
 {
     public void Save()
     {
          SaveChanged(); //...
     }
 }

Answer 1

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

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

• Там, где ожидается изменение, используйте слабосвязанные компоненты
• Там, где ожидается стабильность, Favor тесно связанные компоненты

Это всегда компромисс:

С каждым решением связаны расходы:

Стоимость внесения изменений в тесно связанные компоненты хорошо известна. -Изменение является инвазивным - Чтобы определить все в цепочке зависимостей, может потребоваться много работы Легко пропустить зависимости - Трудно обеспечить качество

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

К вашему примеру: Посмотрите на Пример Stoplight вместе с блоками приложений Microsoft Unity

Answer 2

Общий совет - разделить слои по интерфейсам и использовать контейнеры Dependency Injection и IoC для обеспечения высокого уровня гибкости при поддержке приложения. Но иногда это может быть излишним для небольших приложений, поэтому, чтобы дать вам более конкретный пример, вы должны предоставить хотя бы описание приложения и слоев, которые оно имеет.

Что касается DI, я бы предложил инкапсулировать его в отдельную сборку.

См. Замечательную статью Мартина Фаулера Инверсия управляющих контейнеров и шаблон внедрения зависимостей

РЕДАКТИРОВАТЬ: Ответ на комментарии относительно интерфейса

Единственный способ избавиться от такой связи - хранить общие интерфейсы / классы в отдельной сборке. В вашем случае создайте отдельную сборку и вставьте сюда IUnitOfWork интерфейс.

РЕДАКТИРОВАТЬ: Ссылка Ninject проектов

Есть 147 Ninject проектов, я бы предложил скачать и исследовать наиболее интересные с вашей точки зрения: Ninject проектов

Answer 3

Люди уже ответили на ваш вопрос. Я хотел бы предложить, чтобы «нижний» уровень не ссылался на «верхний» уровень, поскольку цель нижнего уровня состоит в том, чтобы обеспечить определенную функциональность, которая используется вышеприведенным уровнем, и, следовательно, он не должен ничего знать о вышеупомянутом слое. Так же, как хорошая модель слоя стека TCP / IP