Исключение при добавлении записи в таблицу БД

При нажитии на кнопку insert , выдаёт исключение


Вот исключение

0

Сообщение от kotelok сгенерированный запрос с выборкой только тех полей, который запрошены для материализации

Ну как бы отражение идёт всё равно на класс, так что грузятся все поля, которые присутствуют в классе. И в ADO тоже самое, пишешь метод выборки под определённый класс. Просто в EF кода меньше будет вот и вся выгода. Но если в контексте у вас много таблиц, то при каждом запросе в виде using(... new DbContext()...) ждать будете долговато создание контекста, а в ADO только соединение подождать...
Ну везде есть плюсы и минусы

1

Сообщение от Andrey-MSK Ну везде есть плюсы и минусы

Так и есть.

Сообщение от Andrey-MSK то при каждом запросе в виде using(... new DbContext()...) ждать будете долговато создание контекста, а в ADO только соединение подождать...

Долго, вроде, только при первом создании DbContext.
В повторных не замечал лагов.

0

Сообщение от Andrey-MSK Ну как бы отражение идёт всё равно на класс, так что грузятся все поля, которые присутствуют в классе.

Так нет же. EF Core в этом плане весьма умён. Если EF-сущность содержит 40 полей (таблица БД), а в LINQ-запросе при проекции этой сущности в маленький DTO запрашиваются только 4 из них, то конструктор запросов это поймёт, и сделает 'select' к базе с указанием только этих 4-х полей.

Добавлено через 2 минуты

Сообщение от Andrey-MSK то при каждом запросе в виде using(... new DbContext()...) ждать будете долговато создание контекста

Нет, долго будет только в начале, пока контекст "прогревается". Т.е. если я запускаю сервис, в котором используется EF-контекст на полторы сотни таблиц, то любой первый запрос может занимать несколько секунд. Все последующие создания контекстов и запросы выполняются со штатной скоростью. Т.е. EF будет абсолютно неуместен в каких-нибудь сервисах, которые запускают по требованию, отрабатывают и выгружаются. Там да, эта задержка будет критична.

1

Сообщение от kotelok в маленький DTO

Я это и имел ввиду, именно этот класс и отражает данные из запроса и сколько в нём полей, столько и будет заполнено. А сущность - это сущность, это вся таблица в БД. Для ADO тоже пишутся классы таблиц, но и вместе с ними пишется куча классов для нужных запросов. Всё как и в EF.

0

Сообщение от Andrey-MSK Всё как и в EF

Но на деле ведь огромная разница в объёме (и размазанности) кода, а значит и в объёме кропотливой работы, а значит и в повышенных рисках на ошибку из-за необходимости весь этот однотипный код каждый раз руками прописывать, а значит и в болезненном нежелании добавлять новый функционал, т.к. минимальная правка требует помнить о необходимости согласованно подкорректировать группу файлов (в которых ещё и компилятор ничем не поможет, т.к. текст SQL-запросов он вряд ли сопоставит с той сущностью, куда потом выгружается результат).

Т.е. на EF можно написать:И всё, EF за тебя сделает:
1. Построение запроса (с учётом join на Company, с учётом только указанных в мапинге полей).
2. Создание 'DbCommand' и параметров к ней.
3. Заполнение коллекции экземплярами анонимного типа (или конкретного DTO).

И если в будущем потребуется в эту выборку добавить ещё одно поле, то достаточно будет просто добавить одно поле в select-блок. Даже если оно находится где-то в мастер-таблице на несколько уровней выше (т.к. EF сам достроит join до нужного уровня просто по факту наличия 'inv.Company.City.Name' в select-блоке).

1

Сообщение от kotelok то достаточно будет просто добавить одно поле в select-блок

Это если тип анонимный, а если DTO, то придется писать новый класс.
По поводу кучи кода в ADO согласен. Я обычно пишу методы для БД один раз - отладил запрос в SSMS, написал метод доступа с отражением на нужный класс и всё, более его не меняю. Если в БД что-то добавляется, то добавляю еще класс и метод доступа для него.
А вообще стараюсь делать всё в БД - VIEW, SP, UDF. И даже если что-то там кардинально поменяется (что маловероятно по структуре БД, но практически постоянно в компоновке и оптимизации запросов в объектах БД), то объекты БД вернут те же поля как и было ранее, то бишь методы доступа не меняются, а продолжают получать нужные данные из БД как и было до этого.
У меня в БД до сих пор имена полей в таблицах да и названия таблиц на транслите, как сделал 5 лет назад, так и работает, хотя уже много там чего перековырял для оптимизации запросов, но структуру самой БД не трогал, как было так и осталось. Хочется уже поменять, но лень, как прикинешь сколько всего переделывать...

В общем кому как

0