@@Kulibins1 можно задать вопрос? Когда в model мы прописываем модели, в каких случаях нам нужны справочники? То есть когда я могу просто прописать: public int ID {get;set;} public string Description {get;set;} Без ICollection и IList? И запись public Publisher Publisher {get;set;} пишется дважды из-за того что мы связываем таблицы?
@@didartulepbergenov5699 модель и контекст это разные вещи, зачем модели от контекста наследоваться? Есть 2-а основных варианта моделей: 1) модель с данными без логики, 2)модель с логикой. Если мы говорим про модель с логикой, то скорее всего нужно использовать паттерн репозитория.
Мужик, прямо сейчас я готов тебя расцеловать!!!!! Лучший просто. Нигде не найти нормальных гайдов по этой херне, везде какую-то херь говорят. Методов 5 опробовал и только твой дал результат. Ещё раз говорю - лучший!!! ❤❤❤❤❤
Спасибо интересно. А как быть при удалении объектов? К примеру когда у книги есть BookDetails и удаляем книгу(книга удалиться и за ней удалиться и BookDetails?). И еще один момент, как хранить историю изменения?
Удаляется через каскадное удаление. Историю нужно самостоятельно реализовывать, например через триггеры или просто в функции изменения в вашем беке в какую-то другую таблицу писать историю
Это не возбраняется + это необходимо лишь для обеспечения связи. Вы у себя в коде естественно делайте название как вам удобно. Очень много диаметрально противоположных методик именования и тут нет одной правильной для всех.
@@Kulibins1 ок. По мере просмотра возник еще один вопрос (последний, ин ша Аллаh )) - юнит-тесты бэк-энда в случае использования EF Core становятся по сути интеграционными, т.е. каких-то дополнительных интеграционных сверх юнит-тестов при правильном подходе уже просто не имеет смысла делать, верно?
@@ashimov1970 не совсем интеграционными, для этого нужно еще применить реальную базу данных с откатом из снапшота. Например для некоторых бд нет inmemory режима, а вот если есть, тогда будет интеграционный тест. Я больше с PostgreSql сейчас работаю, приходится делать дополнительные ухищрения.
Тема наследования для отношения 1-к-0..1 не раскрыта. BookDetails можно наследовать от Book. Если в DbContext будут DbSet обоих типов, то Books.ToList вернёт сущности "правильных" типов, с учётом наследования. Т.е. коллекция будет содержать как экземпляры класса Book, так и BookDetails.
Отличное видео. А можете рассказать как вы делаете миграции с помощью FluentApi, когда нужно добавить новые поля или таблицы в рабочую базу и какие подводные камни и тд, чтобы не повредить существующие данные?
Если честно, я вот никак не могу понять, а зачем вообще описывать отношения через Fluent? Ну вот то есть, у нас автор имеет несколько книг, мы пишем - b.HasMany(a=>a.Books), но ведь мы в модели автора уже указали поле List, уже создалось отношение, разве нет? И, если мы удалим HasMany, всё ведь также будет работать, разве нет?
Спасибо. Да действительно вроде и задача простая, но когда начинаешь пробовать, то сталкиваешься с проблеммами. Попробую ваш метод.
Всегда пожалуйста.
Мужик спасибо,мало роликов на эту тему,а тут внятно все объяснил показал,молодец
Это просто нечто. Спасибо огромное!!!
Пожалуйста. Рад что полезно 😊
Спасибо вам, Александр!
Странно, что так мало лайков, вполне внятно и доходчиво. Приятная речь, лайк однозначно, спасибо за вашу работу.
Всегда пожалуйста.
отличное объяснение, Александр!
Спасибо 😊
@@Kulibins1 можно задать вопрос? Когда в model мы прописываем модели, в каких случаях нам нужны справочники? То есть когда я могу просто прописать:
public int ID {get;set;}
public string Description {get;set;}
Без ICollection и IList?
И запись public Publisher Publisher {get;set;} пишется дважды из-за того что мы связываем таблицы?
@@didartulepbergenov5699 да паблишер для связи таблиц. У вас может быть в другой сущности связь со справочником
@@Kulibins1 а когда в моделях будет наследование от контекста? То есть почему не записано, как public class Book : DemoContext
@@didartulepbergenov5699 модель и контекст это разные вещи, зачем модели от контекста наследоваться? Есть 2-а основных варианта моделей: 1) модель с данными без логики, 2)модель с логикой. Если мы говорим про модель с логикой, то скорее всего нужно использовать паттерн репозитория.
Мужик, прямо сейчас я готов тебя расцеловать!!!!! Лучший просто. Нигде не найти нормальных гайдов по этой херне, везде какую-то херь говорят. Методов 5 опробовал и только твой дал результат. Ещё раз говорю - лучший!!! ❤❤❤❤❤
спасибо
Спасибо интересно. А как быть при удалении объектов? К примеру когда у книги есть BookDetails и удаляем книгу(книга удалиться и за ней удалиться и BookDetails?). И еще один момент, как хранить историю изменения?
Удаляется через каскадное удаление. Историю нужно самостоятельно реализовывать, например через триггеры или просто в функции изменения в вашем беке в какую-то другую таблицу писать историю
15:50 почему у списка сущностей такое же название как и у его элементов?
Это не возбраняется + это необходимо лишь для обеспечения связи. Вы у себя в коде естественно делайте название как вам удобно. Очень много диаметрально противоположных методик именования и тут нет одной правильной для всех.
@@Kulibins1 ок. По мере просмотра возник еще один вопрос (последний, ин ша Аллаh )) - юнит-тесты бэк-энда в случае использования EF Core становятся по сути интеграционными, т.е. каких-то дополнительных интеграционных сверх юнит-тестов при правильном подходе уже просто не имеет смысла делать, верно?
@@ashimov1970 не совсем интеграционными, для этого нужно еще применить реальную базу данных с откатом из снапшота. Например для некоторых бд нет inmemory режима, а вот если есть, тогда будет интеграционный тест. Я больше с PostgreSql сейчас работаю, приходится делать дополнительные ухищрения.
@@Kulibins1 спасибо! А есть у вас видео на эту тему?
@@ashimov1970 в плане пока.
спасибо! 😍😍
Пожалуйста 😊
Тема наследования для отношения 1-к-0..1 не раскрыта.
BookDetails можно наследовать от Book. Если в DbContext будут DbSet обоих типов, то Books.ToList вернёт сущности "правильных" типов, с учётом наследования. Т.е. коллекция будет содержать как экземпляры класса Book, так и BookDetails.
Отличное видео. А можете рассказать как вы делаете миграции с помощью FluentApi, когда нужно добавить новые поля или таблицы в рабочую базу и какие подводные камни и тд, чтобы не повредить существующие данные?
Уже давно хочу это видео снять.
Если честно, я вот никак не могу понять, а зачем вообще описывать отношения через Fluent? Ну вот то есть, у нас автор имеет несколько книг, мы пишем - b.HasMany(a=>a.Books), но ведь мы в модели автора уже указали поле List, уже создалось отношение, разве нет? И, если мы удалим HasMany, всё ведь также будет работать, разве нет?
Вот не всё так просто, как раз как начинаеш делать, начинаются проблемы, может в последних версиях entity, оно стало работать, нужно перепроверить.