LINQ إلى SQL - كيف تتفاعل الإجراءات المخزنة مع تغييرات DataContext غير المدعومة؟

Question

سأل شخص ما هنا:

"يتيح LINQ-to-SQL استدعاء SPS. إذا كان هذا SP ينفذ تحديث/حذف/إدراج ، هل أحتاج إلى submitchanges () بعد ذلك؟"

وكان الجواب:

"لا أنت لا. سوف يعمل الرمز. إرسال التغييرات لا يهتم إلا بكائنات LINQ المعدلة إلى SQL وليس مخزنة Procs."

أود فقط التوضيح:

(من فضلك معذرة ، أنا جديد نسبيا على LINQ)

نعم ، لكن ألا يتجاوز الإجراء المخزن كائن DataContext وتعديل قاعدة البيانات نفسها؟ (في حين أن LINQ يعدل كائن DataContext فقط ، حتى يتم استدعاء طريقة datacontext.submitchanges ، حيث يقوم بعد ذلك بتعديل قاعدة البيانات)

هل يمكنني الحصول على إجراء مخزن تعديل كائن datacontext الخاص بي بطريقة ما؟ هل يفعل هذا بالفعل؟

هل يمكنني الحصول عليه بحيث

• إذا اتصلت بـ SP مع LINQ (وأنا أفترض أنه يعدل قاعدة البيانات مباشرة) ،
• ثم استخدم LINQ لتعديل كائن DataContext الخاص بي ، وأرسل التغييرات التي أجريتها على كائن DataContext الخاص بي ،

لا يتداخل التغييران المختلفين اللذين أجريتهما (أحدهما مع SP ، والآخر مع LINQ إلى DataContext)؟

ما أريده حقًا هو وسيلة لجعل الإجراءات المخزنة الخاصة بي تعدل datacontext. هل هذا ممكن؟

أود أن أذكر أنني أقوم بتحويل موقع ويب من SQL إلى LINQ الذي قام بتخزين الإجراءات بشكل أساسي ومحاولة اختيار معارك التي تم تخزينها لتحويلها إلى LINQ والتي يجب الحفاظ عليها في SQL وإجراء مكالمات SP مع LINQ.

شكرا لك على مساعدتك ، جيف

Answer 1

FWIW ، اختبار litmus الخاص بنا هو أي نوع من نوع "crud" تافهة والذي يقوم بإدراج / تحديث سجل واحد يمكن أن ينتقل إلى ORM

ومع ذلك ، فإننا نميل إلى ترك Procs الأكثر تقدماً (تحديثات الدُفعات ، أو إجراءات حساسة للغاية للأداء) "كما هي".

لكن نعم ، ستحتاج إلى استدعاء submitchanges () قبل الاتصال بـ proc يعتمد على حالة البيانات التي تم تغييرها في datacontext

ربما لا علاقة لها ، إذا كنت بحاجة إلى التحكم في وحدات العمل ، فابحث عن وضع المعاملات حول الكود الخاص بك؟

Answer 2

إذا قمت بتحديث السجلات عبر PROC المخزنة ، فقد تصبح كائناتك المحملة (وتتبعها) قديمة. إذا قمت بالاتصال بـ SubMitchanges مع كائنات قديمة ، فستحصل على استثناءات التزامن. يمكنك تحديث كائن قديم باستخدام Refresh طريقة على DataContext.