Луковая архитектура - вызов внешних API
Зонтичный вопрос
Где в луковой архитектуре помещаются все компоненты, необходимые для использования внешнего API?
Если он звонит вам, это часть уровня API.
Если вы это называете, это часть уровня инфраструктуры.
Мне не нравится ваша текущая структура проекта, так как я гораздо более склонен разделять слои на отдельные проекты. Тем не менее, это не делает вопрос недействительным, поэтому я оставлю его в покое.
конкретный класс, который создает клиент графа ms, используя свою библиотеку. Я думаю, что это должно быть что-то вроде: «Инфраструктура -> Внешние API -> График -> MyGraphServiceClient.cs»
Я согласен с битом Infrastructure ->. Все остальное очень контекстуально и не может разумно ответить незнакомцу из Интернета.
Это зависит от размера и сложности вашей кодовой базы. Возможно, это единственный элемент инфраструктуры и подразделение не имеет значения. Может быть, это можно отсортировать в папку проекта. Возможно, это гарантирует наличие отдельного проекта, например. Infrastructure.Graphs. Все это возможно (и даже больше).
связанный интерфейс, который, я думаю, будет использоваться моей службой TeamsManagement: «Service.Abstractions -> IMyGraphServiceClient.cs»
Я предполагаю, что Service.Abstractions — это ваш проект интерфейсов. Если да, то я согласен.
Однако будьте очень осторожны с самим интерфейсом, убедитесь, что он не привязан к конкретной технологии (например, Microsoft Graphs). Убедитесь, что интерфейс не зависит от технологии как по имени, так и по поведению (и связанным структурам данных), если, например, ваше приложение неразрывно связано с этой технологией (например, если вы создаете расширение Microsoft Graphs). Приведенный ниже совет предполагает, что вы по своей сути не привязаны к этой технологии. Если да, совет не обязательно применим.
По своей сути любой код, связанный с технологией, принадлежит инфраструктуре и не должен быть виден какой-либо другой части вашей кодовой базы.
Чтобы получить данные, ваш конкретный технологический код должен будет реализовать независимый от технологии интерфейс. Этот интерфейс виден другим частям вашей кодовой базы, потому что это очищенный способ доступа к логике.
Если вы новичок в этом, я бы предложил следующий порядок операций:
- Сначала напишите конкретный класс. Создайте свой код, чтобы он работал так, как вы хотите. Пока не беспокойтесь об интерфейсах. Если вы хотите запустить свой код, либо используйте тестовый проект, либо подключите свою инфраструктуру к какому-либо потребляющему приложению (например, консольному приложению).
- Как только код заработает, отрефакторьте его, чтобы он был настолько чистым, насколько вам нужно/хотите.
- Создайте интерфейс на основе того, с чем вашему потребляющему приложению/тестовому проекту необходимо взаимодействовать, чтобы выполнить необходимую вам логику.
- Оцените этот интерфейс. Показывает ли это, что вы используете Microsoft Graphs? Это могут быть имена методов, используемые классы DTO, имена свойств этих классов DTO,...
- Единственным исключением являются параметры конфигурации, необходимые для настройки клиента, например. строка подключения или определенные конфигурации Graphs.
- Для каждой обнаруженной вами вещи, которая раскрывает технологию, напишите зеркальный элемент, который не раскрывает технологию. Думайте об этом так, будто вы пытаетесь скрыть эту информацию от посторонних глаз.
- При необходимости реорганизуйте логику своей инфраструктуры и добавьте к ней сопоставления, чтобы она преобразовывала элементы, зависящие от технологии, в только что созданные элементы, не зависящие от технологии.
И это должно быть так.
Некоторые люди предпочитают работать наоборот, сначала определяя интерфейс, не зависящий от технологии, и только потом выясняя конкретную логику для его реализации. Я тоже предпочитаю этот подход, но я думаю, что для начала требуется некоторое знакомство с процессом. Для новичка я бы порекомендовал шаги, которые я указал выше.
Прикрепляю к посту несколько видео по теме: