Можно я задам пару вопросов, ответы на которые пытались дать многие, но мне, как новичку, до сих пор не очень понятно. Все они касаются чистой архитектуры в связке с 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)?
Дмитрий, это просто потрясающе, не останавливайтесь!
Спасибо!
Можно я задам пару вопросов, ответы на которые пытались дать многие, но мне, как новичку, до сих пор не очень понятно.
Все они касаются чистой архитектуры в связке с 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) Если кратко, то я использую исключения. Планирую записать ролик по этому вопросу и показать плюсы и минусы.
gracias :)
Спасибо, было бы хорошо если выпускашись видео по теме grpc или workers или еще интереснее имитация бэкенд разработчика, и углубленее в разработку.
Я думаб что видео будут в рекомендациях. Так как спрос ОГРОМНЫЙ, а вижео на русском языке, нету
Снимем. Что имеете ввиду под имитацией бэкенд разработчика? По поводу workers, что больше интересует, Hangfire или что то попроще , например hosted service(background worker)?