Стал разбираться с Entity Framework Core (до этого доводилось работать с Entity Framework года четыре — пять назад). Много непонятного, но с ходу возник вопрос, ответ на который не сумел нагуглить Видимо в гугле забанили.
Есть БД, импортировал ее в код (хотя, судя по описанию нужно было бы наоборот, но не важно). В любом случае, я хочу, чтобы сохранение и изменение данных велось не через sql команды генерируемые EF Core, а через существующие хранимые процедуры БД. Я примерно представляю как отдельно вызвать хранимую процедуру, но передавать "вручную" в нее десятки свойств объекта — это потерять весь смысл EF Core. Да и вообще не вполне логично. Хочется как-то написать так, чтобы при dbContext.SaveChanges() автоматически вызывались соответствующие хранимые процедуры с автоматическим заполнением параметров.
Как?
Здравствуйте, CyberRussia, Вы писали:
CR>Стал разбираться с Entity Framework Core (до этого доводилось работать с Entity Framework года четыре — пять назад). Много непонятного, но с ходу возник вопрос, ответ на который не сумел нагуглить Видимо в гугле забанили.
CR>Есть БД, импортировал ее в код (хотя, судя по описанию нужно было бы наоборот, но не важно). В любом случае, я хочу, чтобы сохранение и изменение данных велось не через sql команды генерируемые EF Core, а через существующие хранимые процедуры БД. Я примерно представляю как отдельно вызвать хранимую процедуру, но передавать "вручную" в нее десятки свойств объекта — это потерять весь смысл EF Core. Да и вообще не вполне логично. Хочется как-то написать так, чтобы при dbContext.SaveChanges() автоматически вызывались соответствующие хранимые процедуры с автоматическим заполнением параметров. CR>Как?
Здравствуйте, CyberRussia, Вы писали:
CR>Стал разбираться с Entity Framework Core (до этого доводилось работать с Entity Framework года четыре — пять назад). Много непонятного, но с ходу возник вопрос, ответ на который не сумел нагуглить Видимо в гугле забанили.
CR>Есть БД, импортировал ее в код (хотя, судя по описанию нужно было бы наоборот, но не важно). В любом случае, я хочу, чтобы сохранение и изменение данных велось не через sql команды генерируемые EF Core, а через существующие хранимые процедуры БД. Я примерно представляю как отдельно вызвать хранимую процедуру, но передавать "вручную" в нее десятки свойств объекта — это потерять весь смысл EF Core. Да и вообще не вполне логично. Хочется как-то написать так, чтобы при dbContext.SaveChanges() автоматически вызывались соответствующие хранимые процедуры с автоматическим заполнением параметров. CR>Как?
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, CyberRussia, Вы писали:
CR>>Стал разбираться с Entity Framework Core (до этого доводилось работать с Entity Framework года четыре — пять назад). Много непонятного, но с ходу возник вопрос, ответ на который не сумел нагуглить Видимо в гугле забанили.
CR>>Есть БД, импортировал ее в код (хотя, судя по описанию нужно было бы наоборот, но не важно). В любом случае, я хочу, чтобы сохранение и изменение данных велось не через sql команды генерируемые EF Core, а через существующие хранимые процедуры БД. Я примерно представляю как отдельно вызвать хранимую процедуру, но передавать "вручную" в нее десятки свойств объекта — это потерять весь смысл EF Core. Да и вообще не вполне логично. Хочется как-то написать так, чтобы при dbContext.SaveChanges() автоматически вызывались соответствующие хранимые процедуры с автоматическим заполнением параметров. CR>>Как?
S>https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-ef-core-5-0-preview-8/ S>Там добавили Table-valued functions
S>Можно создать ХП которая принимает табличные данные S>https://entityframeworkcore.com/knowledge-base/54782689/how-to-call-stored-procedure-with-table-valued-parameter-from--net-core-entity-framework S>https://stackoverflow.com/questions/43961440/using-datatable-as-a-table-valued-parameter-in-ef-core-2-0
S>Ну и триггеры
В своем репертуаре куча бесполезных линков вообще не в тему.
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, Serginio1, Вы писали:
S>>Здравствуйте, CyberRussia, Вы писали:
CR>>>Стал разбираться с Entity Framework Core (до этого доводилось работать с Entity Framework года четыре — пять назад). Много непонятного, но с ходу возник вопрос, ответ на который не сумел нагуглить Видимо в гугле забанили.
CR>>>Есть БД, импортировал ее в код (хотя, судя по описанию нужно было бы наоборот, но не важно). В любом случае, я хочу, чтобы сохранение и изменение данных велось не через sql команды генерируемые EF Core, а через существующие хранимые процедуры БД. Я примерно представляю как отдельно вызвать хранимую процедуру, но передавать "вручную" в нее десятки свойств объекта — это потерять весь смысл EF Core. Да и вообще не вполне логично. Хочется как-то написать так, чтобы при dbContext.SaveChanges() автоматически вызывались соответствующие хранимые процедуры с автоматическим заполнением параметров. CR>>>Как?
S>>https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-ef-core-5-0-preview-8/ S>>Там добавили Table-valued functions
S>>Можно создать ХП которая принимает табличные данные S>>https://entityframeworkcore.com/knowledge-base/54782689/how-to-call-stored-procedure-with-table-valued-parameter-from--net-core-entity-framework S>>https://stackoverflow.com/questions/43961440/using-datatable-as-a-table-valued-parameter-in-ef-core-2-0
S>>Ну и триггеры
D>В своем репертуаре куча бесполезных линков вообще не в тему.
Пусть передает не десятки свойств а таблицу и в хранимой процедуре производит все нужные действия. Кроме того может получить результат в виде таблицы.
Что не в тему?
Здравствуйте, Serginio1, Вы писали:
S>>>Ну и триггеры
D>>В своем репертуаре куча бесполезных линков вообще не в тему.
S> Пусть передает не десятки свойств а таблицу и в хранимой процедуре производит все нужные действия. Кроме того может получить результат в виде таблицы. S>Что не в тему?
Как по твоим линкам найти информацию о перехватывании SaveChanges чтобы запись велась через хранимки?
Заметь не table value functions.
Здравствуйте, Danchik, Вы писали:
D>Здравствуйте, Serginio1, Вы писали:
S>>>>Ну и триггеры
D>>>В своем репертуаре куча бесполезных линков вообще не в тему.
S>> Пусть передает не десятки свойств а таблицу и в хранимой процедуре производит все нужные действия. Кроме того может получить результат в виде таблицы. S>>Что не в тему?
D>Как по твоим линкам найти информацию о перехватывании SaveChanges чтобы запись велась через хранимки? D>Заметь не table value functions.
А зачем перехватывать? У тебя и так есть все изменения. Записывай (передавай в виде DataTable) и очищай. https://www.entityframeworktutorial.net/efcore/changetracker-in-ef-core.aspx
Ну а если тебе нужно получить результат (проблемные записи), то table value functions тебе очень помогут
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Danchik, Вы писали:
D>>Здравствуйте, Serginio1, Вы писали:
S>>>>>Ну и триггеры
D>>>>В своем репертуаре куча бесполезных линков вообще не в тему.
S>>> Пусть передает не десятки свойств а таблицу и в хранимой процедуре производит все нужные действия. Кроме того может получить результат в виде таблицы. S>>>Что не в тему?
D>>Как по твоим линкам найти информацию о перехватывании SaveChanges чтобы запись велась через хранимки? D>>Заметь не table value functions. S>А зачем перехватывать? У тебя и так есть все изменения. Записывай (передавай в виде DataTable) и очищай. S>https://www.entityframeworktutorial.net/efcore/changetracker-in-ef-core.aspx
Человек имеет базу через задницу, а ты ему еще и предлагаешь с EF работать через то же место?
Здравствуйте, Danchik, Вы писали:
S>>А зачем перехватывать? У тебя и так есть все изменения. Записывай (передавай в виде DataTable) и очищай. S>>https://www.entityframeworktutorial.net/efcore/changetracker-in-ef-core.aspx
D>Человек имеет базу через задницу, а ты ему еще и предлагаешь с EF работать через то же место?
По мне так нормальное решение. Всю логику держишь в одном месте.
и солнце б утром не вставало, когда бы не было меня
D>Человек имеет базу через задницу, а ты ему еще и предлагаешь с EF работать через то же место?
А не через задницу это как? Может я в принципе не так к ситуации подхожу. Привык сперва создать таблицы в бд, к ним хранимые процедуры, по необходимости вьюверы.
А сейчас проект, скажем так, требующий изучения множества источников данных, практически каждый день добавляется одна — две таблицы с десятками полей (пока рекорд 111 полей). И как-то уже начинаю задалбываться через ado.net при вызове хранимой процедуры все параметры вручную прописывать.
Источник структуры json, но обычно не в один один, а с правкой по мере необходимости.
Здравствуйте, CyberRussia, Вы писали:
D>>Человек имеет базу через задницу, а ты ему еще и предлагаешь с EF работать через то же место?
CR>А не через задницу это как? Может я в принципе не так к ситуации подхожу. Привык сперва создать таблицы в бд, к ним хранимые процедуры, по необходимости вьюверы. CR>А сейчас проект, скажем так, требующий изучения множества источников данных, практически каждый день добавляется одна — две таблицы с десятками полей (пока рекорд 111 полей). И как-то уже начинаю задалбываться через ado.net при вызове хранимой процедуры все параметры вручную прописывать.
CR>Источник структуры json, но обычно не в один один, а с правкой по мере необходимости.
Ответь на вопрос: для чего тебе понадобились хранимки на запись? Клиент-сервер что-ли пишешь в 2020-м?
Здравствуйте, AlexRK, Вы писали:
ARK>Здравствуйте, Danchik, Вы писали:
D>>Ответь на вопрос: для чего тебе понадобились хранимки на запись? Клиент-сервер что-ли пишешь в 2020-м?
ARK>А что в 2020-м используют вместо клиент-сервера?
Ну я имел ввиду двухзвенку App->DB. В 2020-м в основном трехзвенку App->AppServer->DB.
D>Ответь на вопрос: для чего тебе понадобились хранимки на запись? Клиент-сервер что-ли пишешь в 2020-м?
Для обеспечения целостности данных и отсутствия дублирования записей.
В зависимости от содержания данных может быть необходим предварительный insert в другую таблицу.
В зависимости от значения группы полей данные в текущую таблицу либо добавляются, либо заменяют собой существующие.
Здравствуйте, CyberRussia, Вы писали:
D>>Ответь на вопрос: для чего тебе понадобились хранимки на запись? Клиент-сервер что-ли пишешь в 2020-м?
CR>Для обеспечения целостности данных и отсутствия дублирования записей. CR>В зависимости от содержания данных может быть необходим предварительный insert в другую таблицу. CR>В зависимости от значения группы полей данные в текущую таблицу либо добавляются, либо заменяют собой существующие.
Вопрос в том, зачем у тебя эта логика в базе данных. Обычно она в приложении. А целостность данных обеспечивается транзакциями.
То есть, по моему опыту, хранимки имеют смысл, если ты хочешь ограничить доступ на уровне базы данных.
То есть, пользователи могут лезть в базу напрямую, в обход твоего приложения.
В случае, если с базой работает только твоё приложение, хранимки вообще не имеют смысла.
По сути вопроса. В EF (как и в любом другом) "нормально" работу через хранимки не сделать, IMHO.
Я бы сделал авто-генерацию кода (видел такое пару раз). То есть, пишется T4 шаблон (или более новый вариант, source code generator),
который запускается (на билде допустим), лезет в базу, анализирует ее структуру, и по структуре базы герерирует код для работы с базой через хранимки.
А уж на какой технологии будет код, EF, или "просто так", не суть важно.
bnk>Вопрос в том, зачем у тебя эта логика в базе данных. Обычно она в приложении. А целостность данных обеспечивается транзакциями.
Не надо все валить в одну кучу. БД хранит данные, обеспечивает их целостность, корректность и т.д. и т.п. Приложение занимается бизнес логикой и не должно решать вопросы с которыми лучше и быстрее справляется БД. Это даже если не принимать во внимание, что хранимая процедура работает быстрее, чем Nое количество запросов из приложения в БД.
Транзакции обеспечивают целостности лишь в смысле отсутствия ошибок при выполнении последовательных запросов. Логическую целостность данных в базе они обеспечить не способны, потому что анализ данных это не их задача, да и не умеют.
Здравствуйте, CyberRussia, Вы писали:
CR> Хочется как-то написать так, чтобы при dbContext.SaveChanges() автоматически вызывались соответствующие хранимые процедуры с автоматическим заполнением параметров. CR>Как?
Теоретически, это возможно. Сделали ли это в EFCore — вряд ли. Одно дело — мэппинг пропертей класса на колонки таблицы, другое — некая функция с параметрами, куда каким-то боком надо передать проперти. Соотв. ты обязан аннотировать каждую проперть, какой она параметр по счёту. А если для сохранения одного класса есть ДВЕ разных ХП? Короче, тухляк твоя идея.
Здравствуйте, CyberRussia, Вы писали:
bnk>>Вопрос в том, зачем у тебя эта логика в базе данных. Обычно она в приложении. А целостность данных обеспечивается транзакциями.
CR>Не надо все валить в одну кучу. БД хранит данные, обеспечивает их целостность, корректность и т.д. и т.п. Приложение занимается бизнес логикой и не должно решать вопросы с которыми лучше и быстрее справляется БД.
Похоже на религию
CR>Это даже если не принимать во внимание, что хранимая процедура работает быстрее, чем Nое количество запросов из приложения в БД.
Это не так, AFAIK. Хранимка работает со скоростью составляющих ее запросов. Все базы данных давно научились сохранять кэш компилированных запросов, то есть компиляция хранимки ничего не дает. Просто проверь, удивишься.
CR>Транзакции обеспечивают целостности лишь в смысле отсутствия ошибок при выполнении последовательных запросов. Логическую целостность данных в базе они обеспечить не способны, потому что анализ данных это не их задача, да и не умеют.
В смысле? Если тебе нужно обновить 2 таблицы, то если ты завернешь два insert в транзакцию, они либо оба откатятся, либо оба выполнятся.
Для этого транзакции и нужны.
Кроме ограничения доступа есть еще куча решений, где не желательно таскать данные с сервера.
Например при проведении документа (снятие остатков итд).
При этом документы могут быть достаточно большими по 100 тыс строк. Например сейчас все маркируется и каждая марка отдельная запись.
Кроме того расчет остатков на дату меньше актуальности
Если логика не сильно заморочена, то проще сделать её на сервере.
В 1С как раз такие проблемы и существуют.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Если логика не сильно заморочена, то проще сделать её на сервере.
Я сильно сомневаюсь в том что логику на SQL писать "проще" чем на C# допустим.
По мне, логика на SQL в хранимках это конкретный неподдерживаемый кошмар.
Видимо в гугле забанили.
куча бесполезных линков вообще не в тему.
