وحدة العمل مع مصادر بيانات متعددة؟

Question

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

في نظام به DB واحد و ORM (مثل nhibernate) ، الأمر سهل. يمكن الحفاظ على المعاملة من خلال ORM. ولكن ماذا عن النظام الذي تحجب فيه نماذج المجال المخصصة العديد من مصادر البيانات المتباينة؟ وليس كل مصادر البيانات هذه هي قواعد البيانات العلائقية؟ (يوجد الكثير على نظام الملفات هنا.)

في الوقت الحالي ، أنا عالق في فكرة أنه "لا يمكنك ببساطة الحفاظ على معاملة عبر SQL2005 DB ، و SQL2000 DB ، و DB2 DB ، ونظام الملفات في نفس" عملية الأعمال الذرية ". لذا ، فإن مسؤولية المطورين في الفريق (الذين يعملون بشكل عام بشكل مستقل عن بعضهم البعض) هو الحفاظ على المعاملات يدويًا في الكود. يمكن أن يكون لكل ديسيبل معاملات مناسبة عليها ، ولكن يتم فحص عملية العمل ككل يدويًا وتوازن كل خطوة مهمة على الطريق.

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

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

للرجوع إليها ، عرض 10000 قدم للتصميم الذي أهدف إليه حاليًا هو: مجموعة كبيرة من تطبيقات العميل الصغيرة الممكنة التي تسمى خدمة مركزية تستند إلى الرسائل. الخدمة هي المدخل في "Core Core" ويمكن اعتباره تطبيقًا كبيرًا على طراز MVC. يتم تقديم الطلبات إلى الخدمة (مثل "الإجراءات") التي يتم التقاطها من قبل المعالجات (مثل "وحدات التحكم"). أي شيء إجرائي يذهب هناك. يتفاعلون مع النماذج ، التي تحتوي على جميع قواعد العمل. تنشر النماذج أحداثًا أي مستمعين ("الخدمات"؟ لا يزال هذا الجزء غائمًا في التصميم ويخضع للتحسين) التقاط والتعامل مع التفاعل مع المستودعات (قاعدة البيانات X ، قاعدة البيانات Y ، نظام الملفات ، البريد الإلكتروني ، أي مورد خارجي). كل ما تم تبعته بتهمة التبعية وفقًا لذلك.

آسف على كل الأفعال :) ولكن إذا كان لدى أي شخص أي نصيحة ، أحب أن أسمع ذلك. حتى (خاصة) إذا كانت هذه النصيحة هي "تصميمك سيء ، جرب هذا بدلاً من ذلك ..." شكرًا!

Answer 1

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

ما قمت به هو بناء مستودعات بلدي باستخدام تنفيذ نمط مستودع عام. سيكون نوع المستودع الأساسي دائمًا مراجعًا من قبل الخدمات و UOW. من أجل المناقشة ، سوف نسميها baserepository. ستقتصر "T" على تطبيقات ientity ، والتي تشير إلى كائن المجال. من BaseRepository ، قمت بإنشاء مجموعة أخرى من الفصول الأساسية للتكوين ، مثل SQLBASEREPOSITORY ، XMLBASEREPOSITORY ، إلخ.

يهتم UOW فقط بأن شيئًا ما من النوع baserepository ، حيث توجد الوظيفة الأساسية. سيتم تمثيل CUD الأساسي (من CRUD) ، مما يوفر المكافئات لإنشاء وتحديثات وحذف. ما يمكن أن يفعله كل من هذه هو إنشاء مندوب ووضعه في قائمة انتظار داخل UOW ، أيضًا تمرير معلومات حول نوع المعاملات التي ستكون عليها ، والبيانات المناسبة المطلوبة لإكمالها. ستبدأ UOW في الحفاظ على قائمة بما كان على المستودعات المشاركة في الصفقة ، ولكن لا يزال لا يهتم بنوعه. بشكل فعال ، فإن طابور هنا يشبه التجنيد في معاملة.

حدد BaseRepository طريقة تجريدية تسمى شيء مثل .applychange (). مرة واحدة تم استدعاء .Commit () على UOW ، فإنه سيقوم بإنشاء TransactionScope () ويبدأ في استدعاء السلطات في القائمة ، مرور المعلومات إلى .applychange (). يوجد التنفيذ الفعلي لـ .applyChange () في قاعدة المستودع المحددة ، أي SQLRepositoryBase ، وما إلى ذلك ويمكن تجاوزه بالتنفيذ أيضًا.

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

أتمنى أن أكون أكثر تحديداً في التنفيذ ، لكن الأمر مر أكثر من عام منذ أن رأيت الرمز الآن. أستطيع أن أخبرك أن الأساس للرمز الأصلي قد تم تحمله من الكتاب ، .NET DRIVER DIRVENT مع C#: مشكلة - التصميم - الحل, ، بقلم تيم مكارثي. استندت كمية كبيرة من تنفيذ المستودع الخاص بي على أمثلةه ، مع وجود غالبية كبيرة من تخصيصي في UOWs وتنفيذها.

أتمنى أن يساعد ذلك في شيء! :-)