سؤال

من أجل الاستفادة الكاملة LinqToSql في ASP.net 3.5 من التطبيق ، فمن الضروري إنشاء DataContext دروس (والتي عادة ما يتم ذلك باستخدام مصمم في مقابل 2008).من واجهة المستخدم المنظور ، DataContext تصميم أجزاء من قاعدة البيانات الخاصة بك التي ترغب في فضح من خلال LinqToSql و هو جزء لا يتجزأ في إعداد ORM ملامح LinqToSql.

سؤالي هو:أنا إعداد مشروع يستخدم قاعدة بيانات كبيرة فيها جميع جداول مترابطة في بعض الطريق من خلال المفاتيح الخارجية.أول الميل لجعل واحدة ضخمة DataContext فئة نماذج قاعدة البيانات بأكملها.أن طريقة يمكن من الناحية النظرية (على الرغم من أنني لا أعرف إذا كان هذا سوف تكون هناك حاجة في الممارسة) استخدام المفتاح الخارجي الاتصالات التي يتم إنشاؤها من خلال LinqToSql أن تذهب بسهولة بين الكائنات ذات الصلة في قانون بلدي ، إدراج الكائنات ذات الصلة ، وما إلى ذلك.

ومع ذلك, بعد بعض التفكير ، وأنا الآن أفكر أنه قد يكون من المنطقي أكثر أن إنشاء عدة DataContext فصول ، كل واحد يتعلق مساحة محددة أو منطقية مترابطة القسم ضمن قاعدة البيانات الخاصة بي.قلقي الرئيسي هو أن إنشاء والتخلص واحدة ضخمة DataContext الدرجة في كل وقت العمليات الفردية التي تتصل بمجالات محددة من قاعدة البيانات يكون فرض لزوم فرض على تطبيق الموارد.بالإضافة إلى ذلك, فمن السهل إنشاء وإدارة أصغر DataContext الملفات من واحدة كبيرة.الشيء الذي أود أن تفقد هو أن يكون هناك بعض البعيدة أجزاء من قاعدة البيانات التي قد لا تكون صالحة للملاحة من خلال LinqToSql (على الرغم من سلسلة من العلاقات بينهم في قاعدة البيانات الفعلية).بالإضافة إلى ذلك سيكون هناك جدول الفئات التي قد تكون موجودة في أكثر من DataContext.

أي الأفكار أو الخبرات بشأن ما إذا كانت متعددة DataContexts (المقابلة DB مساحات الأسماء) هي المناسبة بدلا من (أو بالإضافة إلى) واحد كبير جدا DataContext فئة (المقابلة كاملة DB)?

هل كانت مفيدة؟

المحلول

أنا أختلف مع جون الإجابة.على DataContext (أو Linq إلى كيانات ObjectContext) هو أكثر من "وحدة العمل" من اتصال.ويدير تعقب التغييرات ، إلخ.انظر هذا بلوق وظيفة الوصف:

عمر LINQ to SQL DataContext

النقاط الأربع الرئيسية من هذا بلوق وظيفة أن DataContext:

  1. هي مناسبة بشكل مثالي من أجل "وحدة العمل" النهج
  2. هي مصممة أيضا "عديمي الجنسية" عملية الخادم
  3. لم يتم تصميم عاش فترة طويلة من الاستخدام
  4. Should be used very carefully after
    any SumbitChanges() operation.
    

معتبرا أن أنا لا أعتقد أن استخدام أكثر من DataContext أن تفعل أي ضرر في الواقع ، وخلق مختلفة DataContexts لأنواع مختلفة من العمل سوف تساعد على جعل الخاص بك LinqToSql impelmentation أكثر usuable وتنظيمها.الجانب السلبي الوحيد هو أنك لن تكون قادرا على استخدام sqlmetal لصناعة السيارات تولد dmbl.

نصائح أخرى

لقد كان الجدل حول نفس السؤال حين الرجعية المناسب LINQ to SQL على إرث ديسيبل.لدينا قاعدة بيانات قليلا من وابر (150 الجداول) و بعد بعض التفكير والتجريب تم استخدام عدة DataContexts.إذا كان هذا يعتبر مضاد نمط يبقى أن نرى, ولكن الآن فإنه يجعل الحياة يمكن التحكم فيها.

أعتقد أن جون هو الصحيح.

"قلقي الرئيسي هو أن إنشاء والتخلص واحدة ضخمة DataContext الدرجة في كل وقت العمليات الفردية التي تتصل بمجالات محددة من قاعدة البيانات يكون فرض لزوم فرض على تطبيق الموارد"

كيف يمكنك دعم هذا البيان ؟ ما هي التجربة التي تبين أن كبير DataContext هو الأداء عنق الزجاجة ؟ وجود عدة datacontexts هو الكثير مثل وجود قواعد بيانات متعددة و المنطقي في سيناريوهات مماثلة ، وهذا هو بالكاد من أي وقت مضى.إذا كنت تعمل مع عدة datacontexts تحتاج إلى تتبع الكائنات التي تنتمي إلى أي datacontext و لا يمكنك أن تتصل الأشياء التي ليست في نفس سياق البيانات.هذا هو التصميم مكلف رائحة بدون أي فائدة حقيقية.

@إيفان " ، DataContext (أو Linq إلى كيانات ObjectContext) هو أكثر من "وحدة العمل" من صلة" هذا هو بالضبط لماذا يجب أن لا يكون أكثر من واحد datacontext.لماذا تريد أكثر من واحد "وحدة العمل" في وقت واحد ؟

قد نختلف مع الجواب المقبول.في السؤال المطروح ، ونظام واحد قاعدة بيانات كبيرة مع القوي الخارجية مفتاح العلاقات بين الجدول تقريبا (الحال أيضا حيث أعمل).في هذا السيناريو ، تقسيمه إلى أصغر DataContexts (العاصمة) واثنين من فوري و العوائق الرئيسية (سواء ذكر السؤال):

  1. تفقد العلاقات بين الجداول. يمكنك محاولة اختيار العاصمة حدود بحكمة, ولكن في نهاية المطاف سوف تصل إلى حالة يصبح فيها مريحة جدا للاستخدام العلاقة من جدول في واحدة DC إلى طاولة في آخر وأنت لن تكون قادرة على.
  2. بعض الجداول قد تظهر في العديد من العاصمة. هذا يعني أنه إذا كنت تريد إضافة الجدول محددة مساعد أساليب منطق الأعمال ، أو التعليمات البرمجية الأخرى في فئات جزئية ، وأنواع لن تكون متوافقة في جميع أنحاء العاصمة.يمكنك هذا الأمر من خلال وراثة كل كيان فئة من الفئة الأساسية المحددة التي يحصل فوضوي.أيضا, مخطط التغييرات يجب أن تتكرر عبر العديد من العاصمة.

الآن هذه هي عيوب كبيرة.هل هناك مزايا كبيرة بما يكفي للتغلب عليها ؟ السؤال يذكر الأداء:

قلقي الرئيسي هو أن إنشاء والتخلص واحدة ضخمة DataContext الدرجة في كل وقت العمليات الفردية التي تتعلق في مناطق محددة من قاعدة البيانات يكون فرض غير ضرورية فرض على تطبيق الموارد.

في الواقع ليس صحيحا أن كبير DC يأخذ كثيرا من الوقت إنشاء أو استخدام نموذجي في وحدة العمل.في الواقع ، بعد الحالة الأولى التي تم إنشاؤها في تشغيل عملية النسخ اللاحقة من نفس DC يمكن إنشاؤها على الفور تقريبا.

والاستفادة الحقيقية الوحيدة متعددة من العاصمة لفترة واحدة ، قاعدة بيانات كبيرة مع دقيق الخارجية العلاقات الرئيسية هو أنه يمكنك تجزئة التعليمات البرمجية الخاصة بك على نحو أفضل قليلا.ولكن يمكنك أن تفعل هذا بالفعل مع فئات جزئية.

أيضا ، فإن وحدة العمل المفهوم ليس حقا ذات الصلة إلى السؤال الأصلي.وحدة العمل عادة ما يشير إلى كيفية عمل واحدة DC سبيل المثال هو فعل لا كيف الكثير من العمل DC الدرجة هو قادرة على القيام.

في تجربتي مع LINQ to SQL و LINQ إلى كيانات على DataContext مرادف اتصال قاعدة البيانات.حتى إذا كنت تستخدم عدة مخازن البيانات سوف تحتاج إلى استخدام عدة DataContexts.حدسي رد الفعل هو أنك لن تلاحظ أن الكثير من إبطاء مع DataContext يشمل عدد كبير من الجداول.إذا كنت فعلت ذلك يمكنك دائما تقسيم قاعدة البيانات منطقيا في نقطة حيث يمكنك عزل الجداول التي ليس لها أي علاقة إلى مجموعات أخرى من الجداول إنشاء سياقات متعددة.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top