В итоге мало чего объяснил и подача оставляет желать лучшего. В следующих видео постараюсь сделать качественнее, а это можете смело ставить на 2х. Мой телеграм канал - t.me/sachkov_blog
Всё замечательно. Понятно что дальше лучше. Самое главное не опускай руки, так как по .NET очень мало свежих видео и я очень рад что нашёл твой канал так как он очень сильно помог мне в понимание мелких деталей .NET. Спасибо большое)))
@KirillDeveloper видео понравилось, но пример уж слишком простой в данном случае. Мне кажется стоило добавить еще несколько связанных между собой сущностей, чтобы показать как реализовать эту связь в моделях и репозиториях, например как в видео по EF. В любом случае благодарю за видео, продолжай!
Привет. Не мог бы ты пояснить момент. Не понятен смысл существования BookEntity. Действительно ли нам нужно, используя EF codefirst и миграции, юзать эту прослойку? Какие проблемы мы этим решаем? В твоем примере получается просто валидация при чтении из БД, зачем оно надо не понятно. За труды Спасибо, это самый лучший мануал по теме, который мне удалось найти.
Очень интересный видос. Многое непонятно, но это даже здорово, т.к. захотелось углубиться и погуглить отдельно некоторые моменты. Я далек от фронта, но тоже было интересно, хотелось с чего-то начать. Почему бы не начать с того, что предлагает автор. Думаю, что пересмотрю видео ещё раз. Спасибо 😊
record - это функция, введенная в C# 9.0 (выпущена в 2020 году), которая позволяет создавать неизменяемые (immutable) ссылочные типы с меньшим количеством шаблонного кода. Основные характеристики record: Неизменяемость по умолчанию Автоматическая реализация методов Equals(), GetHashCode() и ToString() Поддержка деконструкции Возможность использования позиционных параметров
ExecuteUpdateAsync и ExecuteDeleteAsync - это методы, добавленные в Entity Framework Core 7.0, которые позволяют выполнять массовые операции обновления и удаления без необходимости сначала загружать сущности в память
Добрый день! Я новичок в чистой архитектуре и на пути изучения. У меня появились вопросы. 1) слой core как я понимаю - это доменный слой( бизнес слой, ядро). Если модели данного слоя это бизнес сущность, то не должны ли все остальные слои зависеть от данного слоя? 2) Могу ошибаться, поправьте, пожалуйста, но если в бизнес сущностях что-то поменяется, то нам надо будет в двух слоях менять? 3) Как я понимаю, сеттеры не добавлены были, дабы, проконсультировать нежелательные вставки в свойства? А нельзя ли это проконтролировать в слое выше, в application, так как это слой бизнес процессов. Так же, не протаскивать доменную сущность до слоя Api. Так же, нормально ли в контроллерах выполнять дополнительные действия такие как силекты и прочее, если их можно в слое application, так как повторюсь, это слой бизнес процессов? За ранее спасибо! Я ни в коем случае, не хочу никого задеть, это в целях улучшить знания свои и получить фидбек по пробелам.
Помогите понять чистую архитектуру. Почему в слое DataAccess есть зависимости от EF Core? Я везде нахожу информацию, что зависимости от фреймворков должны быть в .Infrastracture. Это нормальная практика или упрощение? Заранее спасибо
Не знаю задавал ли кто-то этот вопрос, но кто подскажет. В самом начале, когда создавался класс Book, то мы сделали доступное создание новых объектов через статический конструктор. Есть ли название у такого подхода, чтобы почитать побольше или понимать когда его лучше всего использовать? Или возможно это просто элемента какого нибудь паттерна проектирования?
Спасибо, очень познавательно. Есть вопрос: чем плох шаблон "React and ASP.NET Core"? Его используют на практике, или все же обычно используют разделение frontend/backend как в ролике? Спасибо.
Большинство разделяют проекты, чтобы все деплоилось независимо + в шаблоне используется сборщик vite, кому-то может не нравится. Просто если создашь отдельно фронт, то можно вести себя гибче, менять сборщики и тд, поэтому рекомендую делать раздельно
Получается, что валидация происходит не только при создании новой книги, но и каждый раз при получении книг из базы, т.к. там тоже вызывается метод Create. Не будет ли это лишним, в базу ведь и так могли попасть только проверенные значения?
В некоторых случаях dto же находится на уровне бизнес логики , то есть логика возвращает нужный объект для контроллера , а контроллер просто возвращает , то есть в контроллере минимум логики. Такой вариант более правильнее ?
[15:55] Вызов Select после ToListAsync? надо до превращения в лист мэпить. запрос в бд будет чаще всего короче и не придется после создания листа итерироваться по новой
Привет, пару небольших замечаний: 1) Там где const string MAX_TITLE_LENGTH, лучше было его же и вписать в error, вместо магичской 250 2) Вместо кортежа result + error как будто бы напрашивается отдельный класс (Пример у Чапсаса - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-YbuSuSpzee4.html)
У меня постоянно лажа с зависимостями между слоями, а есть больше информации про это? То слой DAL не видит Core то В контроллерах не видно модели или интерфейсы из Core. Как их правильно настраивать, когда несколько проектов в солюшене?
Забавный момент который я не сразу заметил. Тут создается контейнер в Докере и запускается но используется при этом обычный сервер Postgresql если я правильно понял. То есть в данном случаи создание контейнера используется как создание БД схемы а работа с БД ведется напрямую через локальный установленный скорее всего сервер Postgresql, а не в докера , ибо если остановить работу контейнера, то о чудо, работа апи не будет выбрасывать ошибки, что докажет что апи работает с сервером. Но видео при этом очень полезное и достаточно хорошо показывает БАЗУ!)
Подскажите пожалуйста, как он может обращаться к именам других решений. Я имею ввиду, как, будучи в проекте BookStore.DataAccess он может обращаться к моделям из BookStore.Core. таймкод: 12:24
А вот ты создаешь в book.cs метод create и проверяешь title , но даже если у нас будет ошибка в любом случае сожается book ? Если я все правильно понял
Правильнее было бы, сделать возвращаемый тип Book?, и если ошибка есть, то возвращать вместо book - null. А ещё правильнее использовать тип Result, как я делаю в видео про богатую DDD модель
@@KirillSachkov, честно, не совсем понял прикол такой реализации. Даже если возвращать null, то где-то на уровень выше прийдётся каждый раз проверять, что нам вернул метод, а если где-то забыть это сделать, то все приложение сломается. Сомнительная практика. Разве не лучше просто выбрасывать исключения?
@@LightChimera Можно просто выбрасывать исключение, но это менее производительно. Тут кому как больше нравится, либо использовать тип Result и делать проверку каждый раз при создании модели или выбрасывать исключение, но жертвовать производительностью
@@KirillSachkov out of the blue. возвращать null? rly? это худшее зло, что коллекции, что поодиночные объекты вроде так не плохо все сделал и более или менее понимаешь суть, но иногда у тебя такие высказывания проскакивают, что не имеют никакого отношения к clean code, architecture.
Мы в куче разных мест используем поля Guid Id, string Name и тд. И в будущем если появится новое поле, то его надо так же везде в куче мест добавить. Нельзя где-то в одном месте их прописать и во всех классах использовать?
Интересный подход. И всё же есть вопрос. Класс Book, тот , который домейновский, он не противоречит SOLID? Возможно, я что-то не понимаю, но здесь при создании класса у нас одновременно и состояния, и поведение и даже инициализация экземпляра этого же класса, как в Singletone, и там же - валидация. Такое ощущение, как будто мы перегружаем класс. А он является домейновским. Поправьте, если не прав. А вообще объяснение мне очень даже понравилось. Спасибо за труды. Теперь буду следить за вами. Лайк и респект за обучение
12:38 А разве использование константы из Core слоя в Data слое не нарушает принцип обратной зависимости? Не лучше ли будет вынести константу в отдельный конфигурационный файл (например appsettings.json), где будут храниться все константы?
Нет, не нарушает, слой Persistence имеет доступ к доменным моделям, как минимум он их возвращает и принимает в репозиториях, поэтому так можно делать. Конечно желательно, чтобы слой Persistence ссылался на Application, а Application на Domain
dotnet ef migrations add название миграции -p путь до проекта с dbcontext -s путь до проекта с api. В документации эта команда есть, можно загуглить dotnet ef migrations
@@KirillSachkov Тоесть если тебе нужен постгре то достаточно докер-композ, но если хочешь в докер контейнер положить свое приложение, тогда нужен докерфайл. Понял. Спасибо.
Это я удачно залетел. Давно хотел пощупать React за мяхкое место. С меня лайк и подписка. Так држать. И сразу вопрос. Можно ли добавть итолько страницу на реакте. В Существующие mvc приложение net core 6. Например реализовать админку и странице статистики по каким нибуть item"s?
Зачем классы использовать в таких моделях, есть же рекорды? В три раза меньше писанины, а валидацию вынести в отдельные классы с использованием FluentValidation... По поводу архитектуры мог бы порекомендовать вертикальные срезы - хорошо на скрам ложится, например: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-msjnfdeDCmo.htmlsi=Iq6zal9K3DCAAIwE
гайд слабый, хоть и понятно, что хотел донести автор, но всё-таки хотелось бы знать, почему так или не так сделано в каком-то конкретном случае(именно ход мыслей и логическое рассуждение, подкрепленнённые фактами из реальной разработки), понимаю, первое видео - проба пера, и в будущем будет лучше, но на такие вещи сразу лучше обращать внимание
Пока фронт не начал показывать, всё понятно было и без вопросов (за исключением пары моментов), Как только начался фронт... Я перестал улавливать логику... Что за иерархия папок, что за компоненты, несколько файлов с book и т.д.😅 Ощущение, что ты спешил очень куда-то 😅
даа, есть такое. наконец-то закончил делать, но использовал сборщик Vite, чисто из-за привычки (все 1 в один, только роутинг иначе реализовал) поначалу все еще понятно было, но под конец куча файлов, стейтов и все перемешалось в голове короче😓 +либо я пропустил, либо реализация кнопки Add Books появилась магическим образом в конце видео)) + у меня почему-то каждая карточка занимает целую строку, но с этим уже разберусь. А так классный урок, определенно, есть чему поучиться. Спасибо огромное
