Entity Framework Core 5.0 - добавляем базу данных в проект
ฝัง
- เผยแพร่เมื่อ 27 ก.ย. 2024
- Разработка ASP NET Core Web API с нуля профессионально. Видео 3. Entity Framework, добавление базы данных в проект.
Если хотите поддержать канал: pay.cloudtips....
Что будем делать: узнаем, как работает Entity Framework, какие есть подходы к построению базы данных в EF Core, разберем теорию работы Entity Framework'а и закрепим на практике, добавив в приложение возможность работы с базой данных.
Мы в Telegram: t.me/platinum_...
Чат для общения и вопросов: t.me/platinum_...
Код из видео: github.com/and...
Лекция ADO.NET: • ADO NET и Dapper
Technology vector created by vectorjuice: www.freepik.co...
IRepository и UnitOfWork отдельное спасибо.
Вам спасибо!
Отличный формат роликов . После прочтения теории неплохо шлифует знания .
Большое спасибо за ролики. Для начинающих очень быстро и непонятно конечно. Есть какая то литература, которая объясняет подробнее чтобы въехать в суть подробнее.
А по каким таким принципам ты берешь доменную сущность Note и используешь её в DbSet? В DbSet используются сущности, которые будут маппиться на таблицы базы данных и они должны быть развязаны с доменными сущностями. Да и вообще использование DbSet уже говорит о привязке к хранению в БД. А что если завтра я захочу хранить данные в txt файле? Для этого и придумали репозитории. Есть единый интерфейс доступа к данным, который используется приложением, а реализация может меняться и ничего не поломается. Сегодня реализация хранит данные в БД, а завтра я сделаю реализацию, которая будет хранить данные на папирусе, при этом интерфейс останется тем же и можно будет просто перерегистрировать зависимость в контейнере.
Только хотел это написать. Как бы согласен. Да и в случае использования атрибутов для EF будет проще понимать к чему это относится(т.е. EF атрибуты должны быть у EF entities). Ну да придется копировать данные из Entity сущности в Domain сущность. Но в этом суть слоистого подхода.
часто на папирусе данные храните?
@@artcoed часто делаю чистые архитектуры
@@ElectroJam-t7p а я не про это спрашивал
@Сергей Шнуров вы когда реактом пользуетесь тоже абстракции поверх него строите? А вы же можете отказаться отрепозиториев, значит поверх них тоже абстракцию стоит возводить? Не стоит отвечать на неочевидные вещи банальными ответами - в этом дело
Великолепное обьяснение!
А что так резко сложна то стало? 😵💫 и без картинок. Лайк конечно за мастерство. Надеюсь дальше будет понятнее, что от куда, для чего, и зачем... 👍
и раскрасок нет (
хехе, наивный
@@fentan6806 уже давно во всём разобрался. =)
@@BrownAleks как и где разобрался можно гайд?)
Огромное спасибо , все понятно и по делу.
Здравствуйте. Спасибо за видимо. Подскажите, разве бизнес логику не надо выносить отдельно что бы у нас не торчали dbset из интерфейса, например в спецификацию.? Спасибо.
супер
Спасибо!
Здравствуйте, подскажите пожалуйста, что нужно поправить чтоб работать с SqlServer. Меняется же только строка подключения и в классе DependencyInjection проэкта Notes.Persistence
options.UseSqlite(connectionString);
на
options.UseSqlServer(connectionString); или еще что-то?
Я не понимаю почему БД завит от application, я про интрефейс, который в application и используется в БД ?
Бля, вы все не понимаете насколько годную архитектуру чувак сделал.... Этот человек отказался от репо, потому что он шарит и знает что репо это антипаттерн
вам сарказм шикарен)
Отлично. Но что то уроки по времени небольшие. Маловато будет, маловато ))
10 минут оптимально
Зато часто выходят, уж лучше так и дозированно по продолжительности, чем на 2часа и раз в 2 недели
@@mvxburov Тоже логично )))
тут больше зависит от концептуального разделения по темам. в итоге, где-то 5 минут ролик получается, где-то 20. но делать сильно длинные не хотелось, хотелось именно кратко и объемно
Есть архитектурный изъян. Класс DbSet просочился в Application слой. Имеем зависимость Application от Infrastructure
мы это принимаем. DbSet это часть EF, который в свою очередь уже абстракция. используя его мы всё еще независим от выбранной БД и это не противоречит принципам выбранной архитектуры. то есть тут нет прямой зависимости у Application от нашего Infrastructure, но у обоих из них есть использование EF, это правда
@@PlatinumTechTalks на мой взгляд, получилась дырявая абстракция. Ни о какой инверсии зависимостей не может идти речь, когда у нас абстракция в Application слое зависит от DbSet.
Выходит, что Application слой напрямую вызывает методы взаимодействия с сущностью бд, проходя исключительно через абстракцию над реализацией конкретных провайдеров БД. Что не избавляет нас от того, что мы ломимся в EF
Спасибо за уроки, очень полезно! Такой вопрос возник - для чего в интерфейсе INotesDBContext определен метод SaveChangesAsync? если он итак уже реализован в DbContext?
Да, тоже не понял зачем он в интерфейсе вообще
Мы DbContext используем через dependency injection и используем интерфейс INotesDbContext и методы, объявленные в нем. То есть так как мы в командах не используем DbContext напрямую, то и о методе SaveChangesAsync из DbContext’а командам ничего не известно. Тут и приходит на помощь метод из интерфейса
@@PlatinumTechTalks Понял, спасибо за разъяснение )
@@PlatinumTechTalks а как у вас студия не ругается на отсутствие реализации этого интерфейсного метода в классе?
Реализация присутствует в базовом классе (DbContext), наш класс её наследует
Привет, у меня вопрос. Я не совсем понимаю почему, но EF не добавляет данные в базу, точнее так - данные есть, но они не отображаются в MSSQL менеджере. При добавлении и удалении данных всё работает как надо. Но таблицы в менеджере пустые. mdf файла в папке bin\Debag у меня нет
Подача супер! Не коротко и не мало инфы ! А может ли entity framework разделять на bounded context как в нхибернейте? Ну чтобы было несколько контекстов которые не зависят друг от друга и которые нормально мигрируются?
Спасибо большое за отзыв!!
Можно делать всё что угодно :) про DDD и EF можно например посмотреть этот доклад: th-cam.com/video/Z62cbp61Bb8/w-d-xo.html
Почему проект для БД называется Persistance?
Все здорово, но где продолжение? Хотелось бы узнать как ConnectionString задавать таким способом и про миграции
Про EF Core на канале есть отдельное видео с примерами:
th-cam.com/video/eHayUiqBXK4/w-d-xo.html
Здравствуйте! спасибо за уроки!!
в процессе просмотра возникли сл. вопросы:
Почему Ваша студия не отражает ссылки на свойства, методы, классы?
7:04 - не пользуетесь подсказками (чисто теоретически выскакивает помощник, который поможет реализовать интерфейс)
пишите вручную юзинги.
знак => отображается как ⇒
Странная у вас студия)) почему так?
Здравствуйте! Спасибо вам!
Всё прописывалось вручную чтобы было понятно откуда что идет.в реальной жизни пользуемся подсказками конечно же.
Стрелочка и прочее - это специально разработанный шрифт для чтения кода от компании JetBrains.скачать можно на их официальном сайте
Спасибо
вроде все повторила но нет using Notes.Domain , версия 6,0 Core
капец, кликнула на и уже от туда добавила using ,а так небыло)) ну и ладно
блиииин в интерфейсах тоже самое тока тут не подтягиваеться....
вторая ошибка была в том что силку добавила не на Domein , а на NoteAplication)Можно смотреть дальше видио
Насколько трудно будет сделать/переделать приложение под MySQL, а не SQLite, руководствуясь этим вашим плейлистом? Много кода менять придется?
Вам нужно будет поменять строку подключения и провайдера в уровне Persistence. Остальное без изменений, в этом весь смысл независимости в чистой архитектуре от всего внешнего
Что-то не пойму, зачем нужен INotesDbContext, если для тестов можно с таким же успехом подключить EF In-Memory, а то и вообще запустить в памяти Sqlite (с родным вендором код при тесте уж точно отработает именно так, как в реальности)?
А моки дадут такой же результат, как и EF InMemory (хотя не, вызов SaveChanges() не отследить)
INotesDbContext - это описание контракта, мы его можем использовать хоть по всему приложению (и позже это сделаем), а NotesDbContext - это конкретная реализация интерфейса INotesDbContext, которую в целом можно подменить на любую другую реализацию такого же интерфейса (например на DbContext с PostgreSQL) и все части приложения, использующие у себя INotesDbContext подхватят новую реализацию.
Для тестов да, использование EF In-Memory очень правильный вариант. Мы используем наш DbContext, но в параметрах указывем In-Memory базу данных, тем самым абстрагируясь от той, которую используем в действительности.
То есть основная идея тут следующая: интерфейс объявлен на уровне Application и будет использоваться в слое Сценарии (предыдущее видео про чистую архитектуру). Этот уровень оперирует абстракциями и не знает ничего про то как оно реализовано во внешнем мире. Проект Persistence - это уже внешний слой, содержащий реализацию
@@PlatinumTechTalks Аа, это для инверсии зависимости, тогда понятно)
Всё репозитории из головы не выйдут, вот и забыл про этот момент))
Интересный подход, надо будет обдумать на досуге.
Но, наверное, обращение к DbSet через Linq для условного MongoDb сложновато будет обернуть :(
То есть с репозиториями архитектуру можно было бы сделать чище: стало бы возможным менять ORM или провайдеры баз, неподдерживаемых EF-ом.
С другой стороны, если пренебрегнуть гибкостью в этом плане, то будет чище кодовая база: не будет репозиториев, а все обращения к коллекциям сущностей будут инкапсулированы в обработчиках команд/запросов, что, вероятно, мы и увидим в следующих выпусках :-). Правда в этом случае INotesDbContеxt служит лишь для красивой картинки зависимостей, которая не будет отражать реалии, т.к. EF в данном случае подменить не получится...
Поэтому всё-таки встаёт вопрос: почему без репозиториев? Очень высока вероятность, что заметки захочется хранить в NoSql, а само приложение не выйдет настолько большим, чтобы репозитории распухли)
Надеюсь, не слишком много тут пишу) Занимательная тема) хочется подискутировать и узнать опыт других)
Кстати, для перехода на Postgresql и любой другой провайдер, поддерживаемый EF-ом, интерфейс INotesDbContext тоже мало чем поможет, ведь для этого будет достаточно подменить options в фабрике создания NotesDbContext в DI-контейнере.
А вот будут ли после этого linq-запросы транслироваться в ожидаемый sql-запрос - это ещё вопрос...
Репозторий - это абстракция. а EF сам и предоставляет эту абстракцию.
Совершенно другой разговор, если вдруг команда решает что для проекта EF это кусок чего-то нехорошего и решает, что давайте даппер, например, использовать
А так с точки зрения потребления кода нет разницы репозиторий или DbSet. DbSet - делает тоже самое.
Что касается тестирования. Надо исходить из задач. Несмотря на то, что InMemory вариант неплохой, он не всегда может подойти (кстати, сам майкрософт не рекомендует использовать InMemory). У нас например возникала
проблема с констрейнами. то есть, имеются проблемы тестирования схемы базы. Но для тестирования логики подходит. А если нужно тестировать с базой, то это уже вопрос о развертывании интеграционных тестов.
Что касается NoSQL, то например Cosmos DB - это NoSQL база и EF Core её поддерживает. То есть о том как DbSet работает с NoSQL - это не наша забота, это ответственность провайдеров.
INotesDbContex для перехода не нужен, достаточно заменить options, но новый DbContext будет реализовывать всё тот же интерфейс INotesDbContext, который мы используем в приложении.приложению неважно какой DbContext использовать потому что это уже уровень внешних деталей, а внутри мы оперируем абстракциями.
database first кажется убрали кже
куда убрали?
Для новичка довольно сложное объяснение. К каждому предложению возникает много вопросов (
спасибо за отклик, изначально не планировалось что это для новичка :) тут вообще каждая отдельная тема заслуживает отдельного курса... конечно всё не охватить в коротких видео
FluentApi читается легче - аргументация от мамкиного архитектора. Какая гибкость? уже несколько лет сталкиваюсь вот с такими мамкинами архитекторами, которые предлагаю использовать FluentAPI. Это приводит к том, что ты не видишь настоящего названия столбца в таблице, не видишь наложенных констрейнтов. Тебе для этого приходится искать где находится файл с флюентом. Слава богу удалось в одном месте убедить уйти от FluentAPI.
Легче читается это когда ты видишь мэппинг свойства на столбец и прочие атрибуты столбца.
Зачем вы предлагаете открывать два файла, когда можно открыть один?
th-cam.com/video/wkF3csnu2hE/w-d-xo.html
Возможно, вызов base.OnModelCreating должен быть все-таки ДО вызова прочих методов от builder? В моем случае, вызов метода base.OnModelCreating, например, после вызова builder.ApplyConfigurationsFromAssembly, реконфигурирует типы entity по своему (т.е. по дефолту). Так, вызов метода base.OnModelCreating убивает мою настройку целевой таблицы ToTable, сделанной посредством ETC в указанной мною сборке.
Кто из 2023го. Устанавливайте нагет 7й версии, мой ругается на 7й кор
ужасная подача без визуализации и объяснения, а за одно с бешеным темпом
темп и вправду жоский, пришлось х1.75 даж выключать)
всем привет! Можете подсказать в чем проблема?
protected override void OnModelCreating(ModelBuilder builder)
{
builder.ApplyConfiguration(new NoteConfiguration());
base.OnModelCreating(builder);
}
выдает ошибку: Severity Code Description Project File Line Suppression State
Error CS0411 The type arguments for method 'ModelBuilder.ApplyConfiguration(IEntityTypeConfiguration)' cannot be inferred from the usage. Try specifying the type arguments explicitly. Notes.Presistence C:\Users\krasn\source
epos\Notes.Backend\Notes.Presistence\NotesDbContext.cs 17 Active
А разве использование Класса Dbcontext в Domain не будет вводить нас в зависимость от фреймворка EF, на уровне Core? В схеме чистой архитектуры изображено что Уровень Core не должен зависеть от фреймворка.
Вот тот же вопрос, зачем нашему Domain знать про EF вообще
Что-то я не понял а как вы собрались использовать DbContext в Domain? Использовать бд будет Application уровень и то через его-же собственный интерфейс INotesDbContext который не зависит от EF. А реализацию интерфейса представит DI.
Когда нужно создавать первую миграцию?Как я понимаю, после создания уровня infrastructure? Добавив контекст в DI контейнер?
Какие преимущества такой "реализации" репозитория через DbSet?
Учитывая, что дальше используется MediatR, то вся дополнительная логика (сортировка, фильтрация, пагинация, преобразования, и тд) будет:
1) либо в Handler классах прямо в методе Handle
2) либо в доп сервисе, который нужно будет создать, который и будет фактически служить аналогом репозитория.
Это же нарушает солид напрямую, т.к всегда реализация будет прямо в местах, куда прокидывается интерфейс, где есть DbSet.
не совсем понял, зачем определяем метод SaveChanges если его в дальнейшем можно вызвать из DbContext. В чем преимущество такого подхода?
Да благословит вас Аллах👍
Шукран!)
DbContext интерфейс должен быть в infrastructure, не в application слое
Ничего не понял, ну ладно на превьюшке написано "профессионально"
Привет! Подскажите : Если сущностей несколько то как поступить? Делать на каждую сущность контекст или один класс контекста, в котором осуществляется управление всеми сущностями?
Один контекст для всех сущностей которые хранятся в бд
@@maflend2762 спасибо
@@maflend2762 Интерфейс дб контекста тоже один на все сущности в базе, или интерфейсы отдельные под каждую сущность и потом реализация всех этих интерфейсов в одном классе дб контекста?
@@maflend2762 И как быть с классами конфигурации и сущностей? Классы сущностей лучше хранить по разным файлам, но в одной папке в проекте .Domain или вообще все в одном файле? И класс конфигурации один на все сущности или для каждой сущности свой и так же в отдельном файле, но в одной папке?
@@this_is_denys Нашли ответ на ваш вопрос? Столкнулся с таким же
Преогромное спасибо
Привіт, а у visual code немає Microsoft Entity Framework Core.Sqlitе, що можна використати замість цього?)
спробуйте через .NET CLI:
dotnet add package Microsoft.EntityFrameworkCore.Sqlite --version 5.0.11