.net - إطار الكيان وتجمع الاتصال




database entity-framework (3)

  1. يتم معالجة تجمع الاتصالات كما في أي تطبيق ADO.NET آخر. لا يزال اتصال الكيان يستخدم اتصال قاعدة البيانات التقليدية مع سلسلة الاتصال التقليدية. أعتقد أنه يمكنك إيقاف تجميع connnection في سلسلة الاتصال إذا كنت لا ترغب في استخدامه. (اقرأ المزيد عن تجمع اتصال SQL Server (ADO.NET) )
  2. أبدا استخدام السياق العالمي. ObjectContext داخليًا بتنفيذ العديد من الأنماط بما في ذلك "خريطة الهوية" و "وحدة العمل". يختلف تأثير استخدام السياق العام لكل نوع تطبيق.
  3. بالنسبة لتطبيقات الويب ، استخدم سياقًا فرديًا لكل طلب. بالنسبة إلى خدمات الويب ، استخدم سياقًا فرديًا لكل مكالمة. في WinForms أو تطبيق WPF استخدام سياق واحد لكل نموذج أو كل مقدم. يمكن أن يكون هناك بعض المتطلبات الخاصة التي لن تسمح باستخدام هذا النهج ولكن في معظم الحالات هذا يكفي.

إذا كنت تريد معرفة التأثير الذي يحتوي عليه سياق الكائن المفرد لتطبيق WPF / WinForm ، راجع هذه article . تدور حول دورة NHibernate لكن الفكرة هي نفسها.

تصحيح:

عند استخدام EF فإنه بشكل افتراضي تحميل كل كيان مرة واحدة فقط لكل سياق. يقوم الاستعلام الأول بإنشاء كيان instace وتخزينه داخليًا. أي استعلام لاحق يتطلب كيانًا ذا نفس المفتاح يعود هذا المثيل المخزن. في حالة تغيير القيم في مخزن البيانات ، ستستمر في استلام الكيان الذي يحتوي على قيم من طلب البحث الأولي. وهذا ما يسمى نمط خريطة الهوية . يمكنك فرض سياق الكائن لإعادة تحميل الكيان ولكنه سيعيد تحميل نسخة واحدة مشتركة.

لا تستمر أي تغييرات يتم إجراؤها على الكيان حتى تقوم باستدعاء SaveChanges في السياق. يمكنك إجراء تغييرات في كيانات متعددة وتخزينها في وقت واحد. وهذا ما يسمى نمط وحدة العمل . لا يمكنك تحديد الكيان المرفق المعدل الذي تريد حفظه بشكل انتقائي.

الجمع بين هذين النمطين ، وسوف نرى بعض الآثار المثيرة للاهتمام. لديك مثيل واحد فقط من الكيان للتطبيق بأكمله. تؤثر أي تغييرات على الكيان على التطبيق بأكمله حتى إذا لم تكن التغييرات مستمرة بعد (تلتزم). في معظم الأحيان ليس هذا ما تريده. افترض أن لديك نموذج تحرير في تطبيق WPF. أنت تعمل مع الكيان وتقرر إلغاء التعديلات المعقدة (تغيير القيم ، إضافة الكيانات ذات الصلة ، وإزالة الكيانات الأخرى ذات الصلة ، وما إلى ذلك). لكن يتم تعديل الكيان بالفعل في السياق المشترك. ماذا ستفعل؟ تلميح: لا أعرف عن أي CancelChanges أو UndoChanges على ObjectContext .

أعتقد أنه ليس علينا مناقشة سيناريو الخادم. ببساطة مشاركة كيان واحد بين طلبات HTTP متعددة أو مكالمات خدمة ويب يجعل التطبيق الخاص بك عديمة الفائدة. يمكن لأي طلب فقط تشغيل SaveChanges وحفظ بيانات جزئية من طلب آخر لأنك تشارك وحدة عمل واحدة فيما بينها. سيكون هذا أيضًا مشكلة أخرى - السياق وأي تلاعب مع الكيانات في السياق أو اتصال قاعدة البيانات المستخدمة في السياق ليس خيطًا آمنًا.

حتى بالنسبة للتطبيق للقراءة فقط ، لا يعتبر السياق العام خيارًا جيدًا لأنك ربما تريد بيانات جديدة في كل مرة تستعلم فيها عن التطبيق.

لقد بدأت مؤخرًا في استخدام Entity Framework 4.0 في تطبيق .NET 4.0 الخاص بي ، وأنا أشعر بالفضول حيال بعض الأمور المتعلقة بالتجميع.

  1. يتم التحكم في تجمع الاتصالات كما أعرف بواسطة موفر البيانات ADO.NET ، في حالتي من خادم MS SQL. هل ينطبق هذا عند إنشاء سياق كيانات جديدة ( ObjectContext ) ، أي new MyDatabaseModelEntities() المعلمة؟

  2. ما هي مزايا وعيوب أ) إنشاء سياق كيانات عالمية للتطبيق (مثل مثيل واحد ثابت) أو ب) إنشاء وفضح سياق الكيانات لكل عملية / طريقة معينة ، مع using كتلة.

  3. أي توصيات أو أفضل ممارسات أو أساليب مشتركة لبعض السيناريوهات التي يجب أن أعرفها؟


Accoriding to EF6 (4،5 also) documentation: https://msdn.microsoft.com/en-us/data/hh949853#9

9.3 السياق لكل طلب

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


وفقا لدانيال سيمونز:

إنشاء مثيل ObjectContext جديد في عبارة استخدام لكل أسلوب خدمة بحيث يتم التخلص منه قبل إرجاع الأسلوب. تعد هذه الخطوة ضرورية لقابلية تطوير خدمتك. تأكد من أن اتصالات قاعدة البيانات لا تبقى مفتوحة عبر مكالمات الخدمة وأن الحالة المؤقتة المستخدمة بواسطة عملية معينة هي البيانات المهملة التي يتم جمعها عند انتهاء هذه العملية. يقوم نظام Entity Framework تلقائيًا بتخزين البيانات الوصفية وغيرها من المعلومات التي يحتاج إليها في مجال التطبيق ، كما يقوم ADO.NET بتخزين اتصالات قاعدة البيانات ، لذا فإن إعادة إنشاء السياق في كل مرة عملية سريعة.

هذا من مقالته الشاملة هنا:

http://msdn.microsoft.com/en-us/magazine/ee335715.aspx

أعتقد أن هذه النصيحة تمتد إلى طلبات HTTP ، لذا ستكون صالحة لـ ASP.NET. قد يكون تطبيقًا حكوميًا ودهونًا مثل تطبيق WPF هو الحالة الوحيدة للسياق "المشترك".







connection-pooling