Отличное объяснение в меру лаконичное. Помню когда года 3-4 назад когда я пытался разобраться по какому принципу разбивается решение на проекты то не мог найти нормального адекватного объяснения. Сейчас подобных видео становится все больше и это замечательно
Можно я задам пару вопросов, ответы на которые пытались дать многие, но мне, как новичку, до сих пор не очень понятно. Все они касаются чистой архитектуры в связке с efcore: 1. Зачем делать слой абстракции между dbcontext и сервисом? Какая польза от того, что мы для 10 сущностей написали 10 репо и Iрепо? Как сделать репозиторий полезным, а не просто прокси? Многие утверждают, что такой геморрой необходим, для того, чтобы легко поменять orm, если понадобится. Оправдано? Не убедительно. 2. Класс из доменной модели должен храниться в БД или необходимо создать новый класс для бд в инфраструктурном слое? Какие подводные у первого сценария? 3. Транзакции бд. Использовать в хэндлерах/сервисах? Если да, то нужно сделать интерфейс IинструментТранзакций со стартом, коммитом и роллбеком? 4. В доменной моделей возвращать Result.Failure() или генерировать исключение?
1)1. Можно и не писать 10 репо, а написать репо к некоторым рутовым сущностям. 2. Замена ORM: Все идет от того, что чистая архитектура говорит, что домен не должен зависеть от инфры. 3. Полезным он становится если например у вас 1 и тот же запрос используется в десятках местах(легче поддерживать если что то изменилось, + читабельность увеличивается если сложный запрос, + может быть какая то доп логика в репо), также чуть легче тестировать мокая репо.Я в реальном проекте отказывался от репо и самая большая боль была в том, что один и тот же логический метод использовался во многих местах, ну и тестировать было чуть сложнее. Совет такой - попробуйте обойтись без него в своем проекте, чтобы понять плюсы и минусы, возможно те минусы, что вы найдете будут для вас некритичными. Любая библиотека/архитектура это всегда набор компромиссов 2) Я использую прямой объект на БД и все. Из минусов: тесная связь с инфрой, может понадобиться добавить какой то тех. атрибут в модель, который совсем не нужен домену. 3) Можно использовать в EF SaveChanges для управления транзакциями реализуя UoW. Если нужно что то сложнее, то есть context.Database.BeginTransaction, что тоже можно добавить в UoW. 4) Если кратко, то я использую исключения. Планирую записать ролик по этому вопросу и показать плюсы и минусы.
Спасибо, было бы хорошо если выпускашись видео по теме grpc или workers или еще интереснее имитация бэкенд разработчика, и углубленее в разработку. Я думаб что видео будут в рекомендациях. Так как спрос ОГРОМНЫЙ, а вижео на русском языке, нету
Снимем. Что имеете ввиду под имитацией бэкенд разработчика? По поводу workers, что больше интересует, Hangfire или что то попроще , например hosted service(background worker)?
Вообще никакую архитектуру не использовали? Я хочу попробовать себя в +- большом проекте, тоже бот. Думаю брать Mvp, но может быть есть более подходящий вариант?
представлять всю логику в виде объектов со своими свойствами и функциями. например машина. если мы делаем автосервис, то там важна модель, прокат, владельцы, повреждения, комплектация. а если заправка, то нам вообще все равно, что за машина, нам интересно, какое топливо оно потребляет и как ее вообще заправлять. собственно так и выводим важные участки сущности и проектируем приложение от этого. даже если вместо обычных машин будут потом боевые роботы на уране, нас все равно от них нужно только тип питания и как их запитывать. ну и сколько денег потом с них стричь
Отличное объяснение в меру лаконичное. Помню когда года 3-4 назад когда я пытался разобраться по какому принципу разбивается решение на проекты то не мог найти нормального адекватного объяснения. Сейчас подобных видео становится все больше и это замечательно
Огромное спасибо. Очень познавательно. Залип, было нереально интересно.
Дмитрий, это просто потрясающе, не останавливайтесь!
Спасибо!
Спасибо за материал очень интересно
gracias :)
Можно я задам пару вопросов, ответы на которые пытались дать многие, но мне, как новичку, до сих пор не очень понятно.
Все они касаются чистой архитектуры в связке с efcore:
1. Зачем делать слой абстракции между dbcontext и сервисом? Какая польза от того, что мы для 10 сущностей написали 10 репо и Iрепо? Как сделать репозиторий полезным, а не просто прокси? Многие утверждают, что такой геморрой необходим, для того, чтобы легко поменять orm, если понадобится. Оправдано? Не убедительно.
2. Класс из доменной модели должен храниться в БД или необходимо создать новый класс для бд в инфраструктурном слое? Какие подводные у первого сценария?
3. Транзакции бд. Использовать в хэндлерах/сервисах? Если да, то нужно сделать интерфейс IинструментТранзакций со стартом, коммитом и роллбеком?
4. В доменной моделей возвращать Result.Failure() или генерировать исключение?
1)1. Можно и не писать 10 репо, а написать репо к некоторым рутовым сущностям. 2. Замена ORM: Все идет от того, что чистая архитектура говорит, что домен не должен зависеть от инфры. 3. Полезным он становится если например у вас 1 и тот же запрос используется в десятках местах(легче поддерживать если что то изменилось, + читабельность увеличивается если сложный запрос, + может быть какая то доп логика в репо), также чуть легче тестировать мокая репо.Я в реальном проекте отказывался от репо и самая большая боль была в том, что один и тот же логический метод использовался во многих местах, ну и тестировать было чуть сложнее. Совет такой - попробуйте обойтись без него в своем проекте, чтобы понять плюсы и минусы, возможно те минусы, что вы найдете будут для вас некритичными. Любая библиотека/архитектура это всегда набор компромиссов
2) Я использую прямой объект на БД и все. Из минусов: тесная связь с инфрой, может понадобиться добавить какой то тех. атрибут в модель, который совсем не нужен домену.
3) Можно использовать в EF SaveChanges для управления транзакциями реализуя UoW. Если нужно что то сложнее, то есть context.Database.BeginTransaction, что тоже можно добавить в UoW.
4) Если кратко, то я использую исключения. Планирую записать ролик по этому вопросу и показать плюсы и минусы.
Автор, спасибо! Скажите пожалуйста, где можно посмотреть исходный код вашего примера?
Спасибо, было бы хорошо если выпускашись видео по теме grpc или workers или еще интереснее имитация бэкенд разработчика, и углубленее в разработку.
Я думаб что видео будут в рекомендациях. Так как спрос ОГРОМНЫЙ, а вижео на русском языке, нету
Снимем. Что имеете ввиду под имитацией бэкенд разработчика? По поводу workers, что больше интересует, Hangfire или что то попроще , например hosted service(background worker)?
А разве Web, не должен ссылаться только на Infrastructure? на все что есть в проекте он точно не должен ссылаться.
Web это моська проэкта. Так же в нем регистрируются все слои приложения.
Пару лет учу с# ,пилю ботов .И смотря на такой код ,ничего почти не понятно хD .Походу буду и дальше на себя ток работать
Вообще никакую архитектуру не использовали? Я хочу попробовать себя в +- большом проекте, тоже бот. Думаю брать Mvp, но может быть есть более подходящий вариант?
Этот ООП если честно никак не входит в мою голову. Никак не могу понять логику и философию ООП.
представлять всю логику в виде объектов со своими свойствами и функциями. например машина. если мы делаем автосервис, то там важна модель, прокат, владельцы, повреждения, комплектация. а если заправка, то нам вообще все равно, что за машина, нам интересно, какое топливо оно потребляет и как ее вообще заправлять. собственно так и выводим важные участки сущности и проектируем приложение от этого. даже если вместо обычных машин будут потом боевые роботы на уране, нас все равно от них нужно только тип питания и как их запитывать. ну и сколько денег потом с них стричь
зачем писать @event, зачем нужна собачка
event это ключевое слово и зарезервировано для c#. Собака позволяет называть переменные даже с такими словами