Взаимодействие между отдельными проектами одного решения
Есть обычное ASP.NET Core MVC приложение, в котором добавлен Identity, работа с сущностями БД через сервисы (паттерн репозиторий), реализация EmailSender и пара контроллеров, которые просто осуществляют роутинг к представлениям для нескольких моделей из бд и страницам регистрации (Identity). Я правильно понимаю, что вся серверная часть (работа с бд, в т.ч. с почтой и регистрацией) должна быть размещена в отдельном новом проекте в том же решении и не содержать в себе представления, а только API? Как вообще должны связываться два отдельных проекта между собой? Просто отправляются запросы через fetch из клиента по url метода в опубликованном API? То есть например я перехожу на сайт somesite.com/phones, попадаю на страницу, на которой должны быть данные из БД, полученные с помощью fetch('somesite2api.com/getPhones')? Если все это уже где-то описано, дайте, пожалуйста, хотя бы корректное название для того, чтобы это погуглить, потому что я даже не могу нормально сформулировать. Нашел только что-то с HttpClient, но не понимаю, это оно или нет?
Ответы (1 шт):
Я рекомендую прочитать книгу Мартина Фаулера "Чистая архитектура", многие вопросы снимутся сами собой (бонусом -- задумаетесь о новых хороших вопросах).
В том виде, в котором вы задали вопрос ответ тривиален: и так делают, и так, тут нет "лучшего" варианта, нужно ориентироваться на задачу, а вы как профессионал должны уметь оба варианта и уметь понимать, где и при каких условиях лучше тот или иной вариант.
Я недавно отвечал (1, 2), что отдельные проекты могут понадобиться если вы планируете передавать другой команде какие-то отдельные части проекта (чаще всего: контракты) для включения их в код, поэтому если вы работаете один, смежных проектов не предвидится -- то делайте всё в одном проекте, это сократит вам время на разработку.
Другой момент, который следует учесть при разбиении на проекты рассматривается у Фаулера с точки зрения единиц развёртывания. Если у вас многоуровневая (N-tier) архитектура, то задайтесь вопросами: у вас компоненты веб-сервера будут располагаться на том же сервере, что и компоненты работы с БД? Работы с почтой? Если по разным серверам -- тогда разумеется вам придётся делить на отдельные компоненты и тогда разные проекты будут общаться через http (HttpClient), wcf, gRPC и т.п. И разумеется (в книге про это есть) подобные вызовы обойдутся дороже, чем вызовы в рамках одного сервера, а те в свою очередь -- дешевле, чем вызовы из соседнего модуля, класса. Поэтому отталкивайтесь от поставленных задач, думайте как будет проще решить вашу задачу.
Я в своё время начинал с разбиения на несколько проектов. Это значительно удлиняет сроки разработки за счёт дополнительного оверхеда, кроме того мне постоянно приходилось задумываться о том, какой минимальный набор пакетов подключить, чтобы работало (а бывало сразу и не работало сразу, ох и намучался же я попервой!) В принципе, когда я научился делать -- я стал чаще лепить всё в одном проекте, если реальной потребности не было, но поначалу это мне помогало чётче видеть архитектурные границы, отработать этот навык на простых проектах, чтобы не задумываться в сложных. Какой подход вам ближе -- зависит от ваших целей.
Я вам привёл несколько примеров репозиториев на гитхабе, чтобы вы могли не только почитать ответ, почитать книгу -- но и разобрать готовые решения. Там есть как от очень известных в программировании людей качественные проекты, так и менее известные:
- https://github.com/djhmateer/3Commerce.git
- https://github.com/gothinkster/aspnetcore-realworld-example-app.git
- https://github.com/JasonGT/NorthwindTraders.git
- https://github.com/jbogard/contosoUniversityDotNetCore-Pages
- https://github.com/akmetainfo/WallyBackend
Не все они придерживаются подхода сервисы-репозитории, у меня подобных примеров все меньше на винчестере под рукой - всё больше примеров на CQRS+Mediatr, поэтому не стесняйтесь искать свои примеры, если вам именно они нужны.
Также надо понимать, что на гитхабе существует огромное количество проектов и я рекомендую вам оттачивать навык поиска и чтения чужих проектов в поисках интересных решений. Да, поначалу будет трудно, но впоследствии, если набьёте руку -- сможете сразу видеть не конкретные решения, а сразу понимать архитектуру, плюсы и минусы.
Поэтому смотрите проекты, пробуйте писать свои, думайте, тренируйтесь!