Подтвердить что ты не робот

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

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

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

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

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

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

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

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

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

enter image description hereenter image description here

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

2 Я считаю, что материал для инъекций зависимостей будет здесь.

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

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

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

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

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

Ответ 2

  • Да, они ждут решения о зависимости. Эти зависимости должны быть наоборот.
  • Поскольку имя (и исправленные ссылки) подразумевает, что целью является размещение что-то вроде решения IoC Container. Хелперу не место классы, ожидайте вспомогательные классы для целей разрешения.
  • Ядро определяет интерфейсы для DAL или доменных служб. DAL и WebServices реализует эти интерфейсы. Внутри пользовательского интерфейса вы должны использовать реализации DAL или Service через определенные интерфейсы. правильная реализация будет решена с помощью Компонент разрешения зависимостей (взгляните на концепцию "Инверсия управления" или "Инъекция зависимостей" ).
  • Как описано в 3. Главное, что в Core вы помещаете интерфейсы, которые будут реализованы внутри DAL и веб-сервисов. И в Core вы бы реализовали свою реальную бизнес-модель. эта модель может использовать DAL и Web-сервисы через определенные интерфейсы (с помощью компонента разрешения зависимостей).