صافي العضوية مع نمط مستودع

Question

وفريقي في عملية تصميم نموذج المجال والتي سوف إخفاء مختلف مصادر بيانات مختلفة وراء التجريد مستودع موحد. واحدة من الدوافع الرئيسية لهذا النهج هو احتمال كبير جدا أن هذه المصادر البيانات سيخضع لتغيير كبير في المستقبل القريب، ونحن لا نريد أن تكون إعادة كتابة منطق الأعمال عندما يحدث هذا. سوف مصدر بيانات واحد يكون قاعدة عضويتنا الذي تم تنفيذه في الأصل باستخدام الافتراضي مزود ASP.Net العضوية. ويرتبط موفر العضوية إلى مساحة الاسم System.Web.Security ولكن لدينا التوجيهي تصميم تتطلب أن لدينا طبقة نموذج المجال لا تعتمد على System.Web (أو أي التنفيذ / الاعتماد على غيرها من بيئة) لأنها سوف يستهلك في بيئات مختلفة - ولا نريد مواقعنا التواصل مباشرة مع قواعد البيانات.

وأنا أفكر في ما يمكن أن يكون نهجا جيدا للمصالحة بين النهج MembershipProvider مع شركائنا المستخرجة العمارة ن الطبقة. شعوري الأولي هو أننا يمكن أن يخلق "DomainMembershipProvider" التي تتفاعل مع نموذج المجال ومن ثم تنفيذ الكائنات في النموذج الذي تعامل مع مستودع والتعامل مع التحقق من صحة منطق / الأعمال. ان المستودع ثم تنفيذ الوصول إلى البيانات باستخدام أداة الوصول ORM / البيانات (كما هو وبعد المترددين).

هل هناك أية ثغرات كبيرة في هذا النهج - أنا لم يعمل بشكل وثيق مع الطبقة MembershipProvider ذلك قد يكون جيدا في عداد المفقودين شيء. بدلا من ذلك، هناك نهج سوف تظن أن خدمة أفضل للمتطلبات التي وصفتها أعلاه؟

وشكرا مقدما على الأفكار والمشورة.

والتحيات، زاك

Answer 1

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

وأساسا، قررنا عدم استخدام أي تنفيذ MembershipProvider - بدلا من ذلك نحن نستخدم المخصصة الخاصة خدمة العضوية يجلس فوق مستودع. وكان من المهم بالنسبة لنا للحفاظ على قاعدة بيانات aspnet_Membership الحالية لذلك لدينا مستودع قد تتكرر في الأساس المدمج في وظائف SQLMembershipProvider (على الأقل، والجوانب نحتاج منه) - في البداية عبر ينق إلى SQL ولكن نحن الآن بصدد الانتقال إلى NHibernate . وتهدف الخطة إلى استبدال قاعدة بيانات عضوية في عام أو نحو ذلك عندما تتم ترقية كل من مواقعنا لاستخدام النموذج الجديد.

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

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

Answer 2

ومثيرة للاهتمام، وذلك بفضل لنشر الحل النهائي. أنا في وضع مماثل، ولكن الكتابة مخصص Membershipprovider. أنا لا أعرف من أين لوضع مزود لأنه يحتاج إلى الوصول إلى DB وكذلك System.Web مساحة الاسم. ويبدو ان الامر هو فئة واحدة ينتهك هذا الفصل كله من تصميم المخاوف.