Чистая архитектура ASP.NET Core 7
ฝัง
- เผยแพร่เมื่อ 26 พ.ค. 2023
- #excalib #cleanarchitecture #aspnet
Запись на личную консультацию - t.me/excalib_advice_bot
Всем кусь 😺 Часто возникают вопросы про чистую архитектуру, потому что не все её до конца понимают! На самом деле всё проще, чем вам кажется, и я постараюсь вам это объяснить.🎉💻
Telegram channel: t.me/excalib_channel
Telegram chat: t.me/excalib_chat
Vk: excalib88
CleanCoder: blog.cleancoder.com/uncle-bob...
Крутая статья про чистую архитектуру: habr.com/ru/companies/mobileu...
Template ASP.NET Core 7: github.com/jasontaylordev/Cle...
Полностью поддерживаю совет для новичков. Что не нужно пытаться выстраивать какую то "чистую архитектуру" не разобравшись с интсрументами. Сначала нужно поднабить шишек, попробовать сделать пару тройку проектиков. А затем уже можно попробовать применять те или иный концепции из мира проектирования ПО :)
Работаю давно по такой схеме и такой архитектуре. Теперь на вопрос "зачем так сложно?" буду давать ссылку на это видео. Спасибо автору))
Удивительно, что столь полезное видео, имеет так мало просмотров🤔
Спасибо большое за годный контент!
Спасибо!
Spasibo bratan ❤
Tools -> Architecture diagram.
Dependency rule (в юз кейса интерфейс IRepository) и Data flow (По интерфейсу обращаемся к DBRepository по интерефейсу) это просто абсолютно разные вещи. Юз кейсы не знают, что мы обращаемся именно к DB, поэтому депенденси рул не нарушается. А с точки зрения голых данных мы уходим в инфраструктуру. В общем тут лучше 1 пример, вместо 1000 слов.
Ключевая проблема обсуждений архитектуры, много слов и правил и ни одного боевого примера) Спасибо за пример в этом видео
Спасибо, согласен, отлично замечание! (у меня эта диаграмма чуток по-другому называется) ibb.co/rHzrg6Q (моя диаграмма)
однозначно лайк, броу!
сяп!
Спасибо тебе, друг! 8 лет разработки, но до меня не доходило до конца
Как я тебя понимаю:)))
Мужик, спасибо большое! Одно из лучших объяснений на русском!
12:20 Ну это можно сказать проще. Вызывать и зависеть, это разные вещи. Например интрефейсы и DI по сути обрывают классовые зависимости, но оставляют вызовы.
Cпасибо большое за видео!! Можешь пожалуйста снять видео про библиотеку AutoMapper?
Думаю сниму)
@@Excalib спасибо большое!
Добрый день. А где и как хранить фоновые службы? Например какая та очередь задач, скажем bull. Для каждой очереди свой процессор, который выполняет что-то. Как вызывать фоновые службы чтобы они начали работать и запускали use cases? Понятно с API вызов идет напрямую. А без вызова как?
Добрый! Не очень понимаю что такое хранить фоновые службы, я бы вообще делал фоновые службы как отдельный сервис или хотя бы запускаемый проект, просто чтоб было удобно масштабировать
@@Excalib например мы кладем задачу отправки email, и отправка происходит воркером. Вот фоновый сервис
В каком слое хранить Dto и конфигурацию маппера?
Смотря для какого слоя созданы дто и для какого слоя созданы правила маппинга, например если Dto аля GetUserRequest, то такая dto создана для слоя UI, тогда эта дтоха будет лежать в UI слое в проекте Web, и конфигурация для маппинга этой сущности тоже там же, а если это бизнесовая дтоха например для маппинга из Application слоя в Domain, то хранится она должна в Application и конфигурация тоже
Мне бы асп.Кор понять, для начала((
поймешь. Не все сразу.
Не уверен что интерфейс должен находится хрен знает где от свое реализации. Обычно разработчик пишет компонент и представляет интерфейс для всех желающих написать своё расширение. А теперь представь что ты в своём проекте написал какой-то интерфейс и предлагаешь разработчику стороннего проекта его имплеминтировать в своём проекте. Культурный просто промолчит, а я бы послал куда подальше. Вот компонент, вот интерфейс. Тебя ведь никто не заставляет его имплементировать, мы просто указываешь его в своих зависимостях.
Короче, пересмотри ещё раз своё видео и обрати внимание на слои, зависимость между ними и как эта зависимость реализуется в коде.
Дизлайк. Бред полный!
Спасибо, ваше мнение очень ценно!
тут скорее имеется в виду, что интерфейс определяет контракт для работы с ядром. Т.е. в ядре есть какая-то логика, и она допустим хочет уведомлять по почте, и она внешнему миру говорит, что я буду дергать кого-то кто на вход получит тело, тему, получателей. А далее в инфраструктуре реализуется некий отправлятор почты, который в свою очередь может использовать внешние компоненты с каким-то интерфейсом и реализация непосредственной отправки может меняться, но ядру приложения этого знать не надо, и свой интерфейс менять не надо.
Я ошибочно подогнал что если мы используем луковичную архитектуру то каждый слой представляет из себя самостоятельный модуль, но на практике оказалось что все слои объеденяются в модуль и логически связанны между собой.
Можно делить на dll, можно не делить. Я бы делил.
:D
а просто тыкнуть в браузере перевести на русский не? а не объясняться пол видоса, что плохо знаешь английский
я просто русский тоже плохо знаю
@@Excalib "смешно", ха-ха-ха
Зачем ты до человека доебался? Он тебе что-то сделал плохое?
Более того он тебе видео снял, чтобы ты лучше разобрался, а ты неблагодарный токсичный чел. Не надо так.
Если хочешь посоветовать или обратить внимание на что-то - делай это тактично.
Иначе ты просто обесцениваешь весь видос и делаешь неприятно автору.