Отдельные проекты в визуальной студии и папках в одном проекте для микросервисов

Не уверен, что вопрос слишком широк или основан на мнениях. Хотя все равно спросит.

Я читаю валюту через электронную книгу «Архитектура» Microsoft, нашел https: //www. microsoft.com/net/learn/architecture . Он имеет поддерживающее решение, которое находится в Github, https://github.com/dotnet-architecture/eShopOnContainers

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

Это приводит меня к моему вопросу.

При просмотре проекта Ordering.API ( https: //github.com/dotnet-architecture/eShopOnContainers/tree/dev/src/Services/Ordering ) автор решил поместить свой код домена и инфраструктуры в отдельные проекты в API-интерфейс микросервиса, который их использует.

На этом изображении показаны 3 службы, причем заказ выполнен с несколькими проектами

 введите описание изображения здесь>> </a> </p>

<p> Как ни странно, проект раньше делился; с проектом Ordering.Application, который теперь является частью проекта Ordering.API. Это устаревшее изображение в документах демонстрирует это. </p>

<p> <a href= введите описание изображения здесь>> </a> </p>

<p> Учитывая, что Microservices должны быть автономными в том смысле, что они имеют определенный ограниченный контекст, и эти модели домена не должны использоваться вне этой микросервисы, что было бы полезно для структурирования проекта, подобного этому, в отличие от структуры папок внутри проект Ordering.API? </p></body></html>

3 голоса | спросил Darren 24 +03002017-10-24T16:23:39+03:00312017bEurope/MoscowTue, 24 Oct 2017 16:23:39 +0300 2017, 16:23:39

1 ответ


3
  1. Быстрые сборки. Если у вас есть один проект для вашего микросервис, он должен перекомпилировать все (оптимизация компилятора несмотря на это). Если вы разделите код на несколько проектов, только проект, который вы меняете, и проекты, которые зависят от него перекомпилированы

  2. Более условно развязанный код. Даже в микросервисах с узкими, изолированная функциональность, основы развязанного кода все еще применять. Когда у вас разные проблемы в разных, независимых проектов, гораздо проще проверить, что вы разделяли ваши уровни организованным образом. Например, скажите, что вы используя ORM для доступа к данным. Без использования проектов, насколько легко это для вас, чтобы доказать, что вы не используете ORM прямо в своем контроллер? С проектами ваш контроллер находится в другом двоичном чем ваш уровень доступа к данным, поэтому довольно сложно доказать: в вашем проекте контроллера даже нет ссылки на него!

  3. Простые модульные тесты. . Когда ваши материалы отделяются от проектов, вам не нужно включать ссылки на всех сумасшедших третьих лиц которые вы используете для доступа к данным или веб-хостинга, когда вы просто хотите протестировать свою основную бизнес-логику. Конечно, в идеальном мире вы должны иметь 100% -ный охват кода, но мы не в совершенстве Мир. Чем сложнее проверить простые вещи, тем меньше вероятность это они будут протестированы.

  4. Меньшие развертывания. . NET проекты, более или менее, переводят на DLL на стороне вывода (это упрощение, но в целом, это конечный результат, если вы специально не избегаете его). Когда ты только изменить один проект, вам нужно только переустановить одну DLL. (Заметка что это страшная причина выбирать проекты против папок, поскольку вы должны использовать автоматические сборки /развертывания в любом случае, но это причина тем не менее!)

ответил bvoyelr 24 +03002017-10-24T17:20:54+03:00312017bEurope/MoscowTue, 24 Oct 2017 17:20:54 +0300 2017, 17:20:54

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132