Классные видео. Очень хотелось бы новое видео по созданию своего веб проекта. Но на этот раз было бы классно увидеть что-то большее грандиозное, чтобы видео было на 3-5 часов, было бы очень интересно))
ну и ещё мне кажется мутно создавать заместо папок проекты. В данном случае ты создал проект инфраструктуры и поместил в нём класс для работы с внешними приложениями. Как мне кажется, для "работы с внешними приложениями" нужно создать отдельный проект. PS бро, без негатива, ты ультра красавчик, архитектура клёвая. внес лепту для обсуждения :D like
Круто! Спасибо за видео! С помощью чего лучше передавать аргументы из методов контроллера в методы сервисов? В видео показано с помощью доменных моделей, а что если в доменной модели нет того, что приходит с контроллера? Можно ли передать dto модели или лучше просто перечислить аргументы: ServiceMethod(int userId, userName ...) {}
В слое domain можно создать нужные дтомодели, например для фильтров. Или если параметров немного, то можно прямо в метод параметры передать, если их не больше 2-3
Спасибо, за объяснение этой темы на простом языке, но вот эти моменты остались непонятны: 1) Каким образом применяется CreateOrderRequest в методе действия Create. То есть как должен выглядеть запрос от клиента, чтобы он поступил в метод действия Create и при этом был параметром Name? Плохо понял суть этого рекорда. 2) И в какой ситуации уместен второй архитектурный вариант? Мне как новичку он кажется сложнее и непонятно, чем он лучше первого варианта.
Почитай про model binding, клиенту нужно передать json { "name" : "test" }, то есть объект с ключом name. А второй подход нужен для разделения в проекте по фичам, полезно, когда используются подход cqrs. А для новичков лучше использовать первый подход
Я так понял, что ты вместо Repository испольщуешь Store, но суть ведь одна и та же. Также упоминаешь про спецификации и тут же показываешь класс с фильтрами.
Привет подскажи, а сильно ли будет отличаться архитектура с использованием gRPC? И на каком слое будут сервисы, в юз кейсах или на слое с контроллерами?
@@KirillSachkov извини я немного запутался, но получается что контроллер вызывает методы gRPC сервиса находясь с ним на одном слое так? А сервис уже идет дальше?
Если разделяешь приложение на фичи или подход с командами и запросами, то дто должны лежать в application рядом с хэндлером. Если испольуешь просто сервисы, то дто должны лежать в слое с api, например в папке contracts
Благодарю за информацию! Не поятен слой Application, какую функцию он выполняет? Опишу что я понял, если что то не так, прошу поправьте меня. Слой Logic(Core) - содержит бизнес-сущности и интерфейс для каждой сущности с описанием того что можно с ней делать (CRUD операции например) (В идеале он не знает про другие слои) Слой Persistence - содержит логику с ВНУТРЕННИМИ данными (БД приложения, ORM), в нем происходит реализация интерфейсов из слоя Logic(Core). Может содержать более мелкие сущности. Слой Infrastructure - содержит логику с ВНЕШНИМИ данными (например какие либо APIшки), в нем так же происходит реализация интерфейсов из слоя Logic(Core). Слой Web API/ MVC - слой клиента, ссылается на все слои. Еще может быть доп. слой Tests - слой с тестами приложения.
Здравствуй. Всё шикарно, но всё ещё не понимаю момент. вижу у большинства такое деление проекта на слои,но написавши 5 проектов и всегда разделявши слои на обычные папки так и не увидел разницы. Объясни, будь добр, в чем недостаток и различие?
Как минимум не получится сборку одного проекта, например доменную область, использовать в других проектах. Разбиение по папкам не устанавливает физическую защиту от компонентов. Например если в приложении есть репозитории, то подразумевается их использование в сервисах, если делать через папки, то ничего не мешает получить ссылку на тот же dbcontext.+ Все слои кроме api, должны быть максимально независимы и общаться через контракты, когда у тебя папки, то ничего не мешает использовать реализации, вместо интерфейсов.
с толку сбивает реализация паттерна репозиторий. Ты не создаешь интерфейс INameRepository, а создаешь INameStore (что значит store) и пихаешь его на уровень Domain. По логике, всё что взаимодействует с базой находится на уровне Infrastructure или, как ты отделил, на уровне Persistance
Конечно по проще бы объяснял было бы классно, не все новички понимают что такое юзкейс и т.д. вместо этого как то более попроще слова подбирал бы... констракт.. хз что это, очень тяжело въезжать когда новичок. примерно как в SimpleCode канал.. там автор как для тупых объясняет.. все понятно. а так молодец, канал топ.
как раз все понятно, нужно быть полным дураком что бы не понять что такое контракт :) Да и не совсем соглашусь с твоим мнением, потому как совсем новички не будут смотреть как построить архитектуру приложения, а тем кто уже имеет определенный опыт, нужно расширять словарь :)
@@Georgiy_AK работаю по направлению проектирование многоэтажных домов по разделу КЖ главным конструктором. так получилось что пару лет назад перешли с автокада в ревит и требовалось знание шарпа. потом затянуло в веб.. профессиональных знаний в вебе не имею, но пару сайтов уже сделал, простых правда.. Поэтому и терминов многих не понимаю, в отличии от самого материала, который автор излагает, и поэтому сложновато осмысливать данное видео.. Но если ты работаешь в данной сфере, то мне кажется тебе не особо должно быть интересно это видео, если ты только не начинающий джун. и да.. молодец что хоть ты не полный дурак, хоть ктото...!
@@Georgiy_AK Конечно по проще бы объяснял было бы классно, не все новички понимают что такое юзкейс и т.д. вместо этого как то более попроще слова подбирал бы... констракт.. хз что это, очень тяжело въезжать когда новичок. примерно как в SimpleCode канал.. там автор как для тупых объясняет.. все понятно. а так молодец, канал топ.
Это не чистая архитектура, а "отсебятина". Посмотрите на картинку дядюшки Боба и поймите где у него живет DB. Как только вы свой слой Logic (Entities - по Бобу) связали со своим слоем Persistence - у Вас все пошло не так. В книге, дядюшка Боб специально для Вас написал отдельную главу База данных - это деталь
Мой телеграмм канал с роадмап для начинающих и полезным контентом - t.me/sachkov_blog
Классные видео. Очень хотелось бы новое видео по созданию своего веб проекта. Но на этот раз было бы классно увидеть что-то большее грандиозное, чтобы видео было на 3-5 часов, было бы очень интересно))
Твой канал просто находка, спасибо)
Ещё не посмотрел, а лайк поставил. Контент в кайф как и всегда
Ждём глубокое видео по автотестированию! С теорией
Спасибо огромное, очень приятно смотреть ваши видео :)
Контент топ! Давно хотел качественного материала по этой теме
Круто! Спасибо за видос. Очень информативно.
Как раз пишу pet project и еще раз убедился, что мне достаточно DAL, DOMAIN и WebAPI.
Спасибо, здорово!
Большой тебе респект, материал просто сказка
Было бы классно эти проекты иметь возможность посмотреть в репозитории, чтобы потрогать его, взять кусочки или дописать по своему.
Ну наконец-то видео для новичков, обрадовался я. Но посмотрев, опять ничего не понял 🤦♂
Спасибо за видео
Спасибо, годнота🤗
Можешь сделать видео по unit тестам
Можешь сделать видео по тестам
Спасибо за ролик. Когда выйдет видео про onion архитектуру?🤔
А разве не должно быть Persistense -> Application -> Core (Logic)?
ну и ещё мне кажется мутно создавать заместо папок проекты. В данном случае ты создал проект инфраструктуры и поместил в нём класс для работы с внешними приложениями. Как мне кажется, для "работы с внешними приложениями" нужно создать отдельный проект.
PS бро, без негатива, ты ультра красавчик, архитектура клёвая. внес лепту для обсуждения :D like
Круто! Спасибо за видео!
С помощью чего лучше передавать аргументы из методов контроллера в методы сервисов? В видео показано с помощью доменных моделей, а что если в доменной модели нет того, что приходит с контроллера? Можно ли передать dto модели или лучше просто перечислить аргументы: ServiceMethod(int userId, userName ...) {}
В слое domain можно создать нужные дтомодели, например для фильтров. Или если параметров немного, то можно прямо в метод параметры передать, если их не больше 2-3
Спасибо, за объяснение этой темы на простом языке, но вот эти моменты остались непонятны:
1) Каким образом применяется CreateOrderRequest в методе действия Create. То есть как должен выглядеть запрос от клиента, чтобы он поступил в метод действия Create и при этом был параметром Name? Плохо понял суть этого рекорда.
2) И в какой ситуации уместен второй архитектурный вариант? Мне как новичку он кажется сложнее и непонятно, чем он лучше первого варианта.
Почитай про model binding, клиенту нужно передать json { "name" : "test" }, то есть объект с ключом name. А второй подход нужен для разделения в проекте по фичам, полезно, когда используются подход cqrs. А для новичков лучше использовать первый подход
а если бд 2 и больше ? к примеру одни данные мы получаем с одной базы через дапер, другие данные через ef и тд. как в таком случае поступать?
Я так понял, что ты вместо Repository испольщуешь Store, но суть ведь одна и та же. Также упоминаешь про спецификации и тут же показываешь класс с фильтрами.
Привет подскажи, а сильно ли будет отличаться архитектура с использованием gRPC? И на каком слое будут сервисы, в юз кейсах или на слое с контроллерами?
В слое с контроллерами, а бизнес логика в use cases все равно
@@KirillSachkov извини я немного запутался, но получается что контроллер вызывает методы gRPC сервиса находясь с ним на одном слое так? А сервис уже идет дальше?
Спасибо! Всё понять не могу, в каком слое должен лежать дто?
Если разделяешь приложение на фичи или подход с командами и запросами, то дто должны лежать в application рядом с хэндлером. Если испольуешь просто сервисы, то дто должны лежать в слое с api, например в папке contracts
Благодарю за информацию! Не поятен слой Application, какую функцию он выполняет? Опишу что я понял, если что то не так, прошу поправьте меня.
Слой Logic(Core) - содержит бизнес-сущности и интерфейс для каждой сущности с описанием того что можно с ней делать (CRUD операции например)
(В идеале он не знает про другие слои)
Слой Persistence - содержит логику с ВНУТРЕННИМИ данными (БД приложения, ORM), в нем происходит реализация интерфейсов из слоя Logic(Core). Может содержать более мелкие сущности.
Слой Infrastructure - содержит логику с ВНЕШНИМИ данными (например какие либо APIшки), в нем так же происходит реализация интерфейсов из слоя Logic(Core).
Слой Web API/ MVC - слой клиента, ссылается на все слои.
Еще может быть доп. слой Tests - слой с тестами приложения.
Здравствуй.
Всё шикарно, но всё ещё не понимаю момент. вижу у большинства такое деление проекта на слои,но написавши 5 проектов и всегда разделявши слои на обычные папки так и не увидел разницы. Объясни, будь добр, в чем недостаток и различие?
Как минимум не получится сборку одного проекта, например доменную область, использовать в других проектах. Разбиение по папкам не устанавливает физическую защиту от компонентов. Например если в приложении есть репозитории, то подразумевается их использование в сервисах, если делать через папки, то ничего не мешает получить ссылку на тот же dbcontext.+ Все слои кроме api, должны быть максимально независимы и общаться через контракты, когда у тебя папки, то ничего не мешает использовать реализации, вместо интерфейсов.
@@KirillSachkov, спасибо!🙂
Аж страшно стало от стольких недостатков, пойду менять структуру последнего проекта, пока не разросся 😂😂
с толку сбивает реализация паттерна репозиторий. Ты не создаешь интерфейс INameRepository, а создаешь INameStore (что значит store) и пихаешь его на уровень Domain. По логике, всё что взаимодействует с базой находится на уровне Infrastructure или, как ты отделил, на уровне Persistance
А если все контракты вынести в отдельную сборку
Можно
Конечно по проще бы объяснял было бы классно, не все новички понимают что такое юзкейс и т.д. вместо этого как то более попроще слова подбирал бы... констракт.. хз что это, очень тяжело въезжать когда новичок. примерно как в SimpleCode канал.. там автор как для тупых объясняет.. все понятно. а так молодец, канал топ.
как раз все понятно, нужно быть полным дураком что бы не понять что такое контракт :) Да и не совсем соглашусь с твоим мнением, потому как совсем новички не будут смотреть как построить архитектуру приложения, а тем кто уже имеет определенный опыт, нужно расширять словарь :)
@@Georgiy_AK работаю по направлению проектирование многоэтажных домов по разделу КЖ главным конструктором. так получилось что пару лет назад перешли с автокада в ревит и требовалось знание шарпа. потом затянуло в веб.. профессиональных знаний в вебе не имею, но пару сайтов уже сделал, простых правда.. Поэтому и терминов многих не понимаю, в отличии от самого материала, который автор излагает, и поэтому сложновато осмысливать данное видео.. Но если ты работаешь в данной сфере, то мне кажется тебе не особо должно быть интересно это видео, если ты только не начинающий джун. и да.. молодец что хоть ты не полный дурак, хоть ктото...!
@@Georgiy_AK Конечно по проще бы объяснял было бы классно, не все новички понимают что такое юзкейс и т.д. вместо этого как то более попроще слова подбирал бы... констракт.. хз что это, очень тяжело въезжать когда новичок. примерно как в SimpleCode канал.. там автор как для тупых объясняет.. все понятно. а так молодец, канал топ.
Это не чистая архитектура, а "отсебятина". Посмотрите на картинку дядюшки Боба и поймите где у него живет DB. Как только вы свой слой Logic (Entities - по Бобу) связали со своим слоем Persistence - у Вас все пошло не так. В книге, дядюшка Боб специально для Вас написал отдельную главу База данных - это деталь
плохо что не показываешь как проект с 0 создаешь, этого мне лично не хватает
Я нашел золота
Кафка - это брокер, а не дб 😂
Динозавры ООП учат веб программированию 😂😂😂 - проснись! Ты под капот хоть заглядывал? Ездишь на корыте!