Чистая архитектура в ASP.NET Core. Структура реального проекта

[@Денис-д1у2д]

Автор, спасибо! Скажите пожалуйста, где можно посмотреть исходный код вашего примера?

[@dobrinyanicitich7514]

Спасибо за материал очень интересно

[@alexandralikin3830]

Дмитрий, это просто потрясающе, не останавливайтесь!

[@DmitryIurevich]

Спасибо!

[@davidmares6053]

gracias :)

[@Александр-ш8я6н]

А разве Web, не должен ссылаться только на Infrastructure? на все что есть в проекте он точно не должен ссылаться.

[@ENDRICO-uz8rk]

Спасибо, было бы хорошо если выпускашись видео по теме grpc или workers или еще интереснее имитация бэкенд разработчика, и углубленее в разработку. Я думаб что видео будут в рекомендациях. Так как спрос ОГРОМНЫЙ, а вижео на русском языке, нету

[@DmitryIurevich]

Снимем. Что имеете ввиду под имитацией бэкенд разработчика? По поводу workers, что больше интересует, Hangfire или что то попроще , например hosted service(background worker)?

[@lamenzyt4624]

Можно я задам пару вопросов, ответы на которые пытались дать многие, но мне, как новичку, до сих пор не очень понятно. Все они касаются чистой архитектуры в связке с efcore: 1. Зачем делать слой абстракции между dbcontext и сервисом? Какая польза от того, что мы для 10 сущностей написали 10 репо и Iрепо? Как сделать репозиторий полезным, а не просто прокси? Многие утверждают, что такой геморрой необходим, для того, чтобы легко поменять orm, если понадобится. Оправдано? Не убедительно. 2. Класс из доменной модели должен храниться в БД или необходимо создать новый класс для бд в инфраструктурном слое? Какие подводные у первого сценария? 3. Транзакции бд. Использовать в хэндлерах/сервисах? Если да, то нужно сделать интерфейс IинструментТранзакций со стартом, коммитом и роллбеком? 4. В доменной моделей возвращать Result.Failure() или генерировать исключение?

[@DmitryIurevich]

1)1. Можно и не писать 10 репо, а написать репо к некоторым рутовым сущностям. 2. Замена ORM: Все идет от того, что чистая архитектура говорит, что домен не должен зависеть от инфры. 3. Полезным он становится если например у вас 1 и тот же запрос используется в десятках местах(легче поддерживать если что то изменилось, + читабельность увеличивается если сложный запрос, + может быть какая то доп логика в репо), также чуть легче тестировать мокая репо.Я в реальном проекте отказывался от репо и самая большая боль была в том, что один и тот же логический метод использовался во многих местах, ну и тестировать было чуть сложнее. Совет такой - попробуйте обойтись без него в своем проекте, чтобы понять плюсы и минусы, возможно те минусы, что вы найдете будут для вас некритичными. Любая библиотека/архитектура это всегда набор компромиссов 2) Я использую прямой объект на БД и все. Из минусов: тесная связь с инфрой, может понадобиться добавить какой то тех. атрибут в модель, который совсем не нужен домену. 3) Можно использовать в EF SaveChanges для управления транзакциями реализуя UoW. Если нужно что то сложнее, то есть context.Database.BeginTransaction, что тоже можно добавить в UoW. 4) Если кратко, то я использую исключения. Планирую записать ролик по этому вопросу и показать плюсы и минусы.

[@ghoulking715]

зачем писать @event, зачем нужна собачка

[@DmitryIurevich]

event это ключевое слово и зарезервировано для c#. Собака позволяет называть переменные даже с такими словами