Луковая Архитектура - PullRequest
Новая
       47

Луковая Архитектура

22 голосов
/ 21 июля 2011

Я настраиваю структуру проекта для предстоящего внутреннего приложения, пробующего Onion Architecture, предложенного Палермо (http://jeffreypalermo.com/blog/the-onion-architecture-part-3/).

Я следовал его указаниям, однако мне пока требуется некоторая проверка структуры проекта.

Перед диаграммами вопросы:

  1. Я думаю, что все ссылки верны (настроены согласно схеме, где стрелка означает «имеет ссылку на») но некоторые проверки были бы хороши.

  2. Что я должен добавить в слой разрешения зависимостей? Это где Помощники уходят? Это относится ко всем другим проектам?

  3. Как веб-службы и пользовательский интерфейс взаимодействуют с DAL? (Через ядро? Как?)

  4. Что должно идти куда? [Широкий вопрос, который я знаю ...]

Упрощенная концептуальная схема выглядит следующим образом (Папки представляют пространства имен):

enter image description here enter image description here

Ответы [ 2 ]

7 голосов
/ 21 июля 2011

Я думаю, что все ссылки верны (настроены согласно схеме, где стрелка означает «имеет ссылку на»), но некоторая проверка будет хорошей.

1 Это выглядит нормально, но я не уверен, что это хорошая идея - вставить разрешение зависимости в диаграмму.

Что я должен добавить в слой разрешения зависимостей? Это где помощники идут? Это относится ко всем другим проектам?

2 Я полагаю, что здесь есть материал для внедрения зависимостей.

Как веб-службы и пользовательский интерфейс взаимодействуют с DAL? (Через ядро? Как?)

3 Это ядро ​​согласно диаграмме Палермо. В основном у вас будут репозитории, в которых будут использоваться модели DAL и доменов, а также сервисы (не веб-сервисы), связанные с репозиториями и моделями доменов. И пользовательский интерфейс / веб-сервисы будут в основном общаться с сервисами.

Что должно идти куда? [Широкий вопрос, который я знаю ...]

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

Архитектура Onion стала для меня очевидной, когда я понял DDD и необходимые шаблоны проектирования, такие как MVC, внедрение зависимостей, репозиторий / служба, ORM.

6 голосов
/ 21 июля 2011
  1. Да, ожидайте разрешения зависимости. Эти зависимости должны быть наоборот.
  2. Как следует из названия (и исправленных ссылок), его цель - хост какое-то решение IoC Container. Это не место для помощника классы, ожидайте вспомогательные классы для целей разрешения.
  3. Ядро определяет интерфейсы для DAL или доменных служб. DAL и WebServices реализует эти интерфейсы. Внутри интерфейса вы бы использовали реализации DAL или Service через определенные интерфейсы. правильная реализация будет решена с помощью Компонент разрешения зависимостей (взгляните на концепцию «Инверсия контроля» или «Инъекция зависимости»).
  4. Как описано в разделе 3. Главное, чтобы в Core были размещены интерфейсы, которые будут реализованы внутри DAL и веб-служб. А в Core вы бы реализовали свою реальную бизнес-модель. эта модель может использовать DAL и веб-службы через определенные интерфейсы (с помощью компонента разрешения зависимостей).
...