Оптимизация хранимых процедур, чтобы они правильно обрабатывались Linq2SQL

Question

Там, где я работаю, нам необходимо пройти через хранимые процедуры как механизм доступа к нашим данным через код. Я использую LINQ2SQL, чтобы минимизировать эту боль, чтобы я мог работать с объектами вместо ADO.NET напрямую. У меня есть ситуация, когда Linq2SQL использует одну из моих хранимых процедур для генерации кода, где тип возвращаемого значения из хранимого вызова proc - int. Хранимая процедура фактически возвращает набор данных. Проведя небольшое исследование, я обнаружил, что это потому, что библиотека SQLClient не может правильно проанализировать sproc для генерации ожидаемых метаданных, которые Linq2SQL использует для создания графа объектов. Мой вопрос заключается в том, как структурировать sprocs (даже сложные) так, чтобы вы получали объектный граф из linq2sql, или, другими словами, чего вам следует избегать в своей хранимой процедуре, которая создаст путаницу для библиотеки SQLClient, чтобы не понимать, как сгенерировать метаданные, которые использует linq2sql для создания графа объектов?

Answer 1

Это на самом деле не ограничение LINQ to SQL, а скорее SQL Server, который не всегда может сказать клиенту, какой будет тип возвращаемого значения, фактически не запуская его, если он содержит временные таблицы, курсоры или динамический SQL.

Поскольку запуск с недопустимыми параметрами может быть потенциально катастрофическим, он не пытается.

Вы можете установить его вручную, используя конструктор, или, если это абсолютно нормально , запустить хранимую процедуру с недопустимыми данными (т.е. она является чисто пассивной), затем вы можете добавить SET FMTOPT OFF в начало хранимой процедуры.

Answer 2

DamienG работает в команде LinqToSql в Microsoft, и я назвал его ответ верным.

При этом он, скорее всего, не посоветует вам отказаться от LinqToSql, и я думаю, что очень важно рассмотреть этот вариант.

Попытка угадать тип возврата хранимой процедуры очень сложна, и LinqToSql делает это так же, как и любой другой (для SQL Server).Тем не менее, есть очень веские причины не использовать хранимые процедуры:

Хранимые процедуры плохие, хорошо?

Если вы должны защитить свои таблицы от разработчиков для«соображения безопасности» (я полагаю, это ситуация, в которой вы находитесь), лучше всего делать это с представлениями, а не с хранимыми процедурами.

Если вы используете представления, у вас тогда будет намного лучшие варианты вОтдел ORM, чем LinqToSql.

Основная проблема, с которой вы столкнетесь с LinqToSql, заключается в том, что то, что работает нормально для 5 хранимых процедур в крошечной базе данных, не работает нормально для 50 или 500 хранимых процедур.,Вы можете использовать O / R Designer для «переопределения» возвращаемого типа хранимой процедуры, но у вас будут существенные проблемы с синхронизацией, когда хранимые процедуры или таблицы и т. Д. Работают при изменении.Изменения в хранимых процедурах не будут отражены в O / R Designer, если вы не удалите хранимую процедуру из O / R Designer, повторно добавите ее, а затем повторно примените свое пользовательское переопределение.Если ваш проект похож на обычный проект, таблицы и хранимые процедуры часто меняются, и эта проблема синхронизации вскоре становится кошмаром, потому что она полностью ручная, и если вы не сделаете это правильно, вы получите очень странные ошибки во время выполнения.

Я бы настоятельно рекомендовал не идти по пути, по которому вы идете.