عضوية .Net في تطبيق nTier

Question

لنفترض أن لدي تطبيق ASP.Net MVC وهذا التطبيق (UI) يشير إلى طبقة منطق الأعمال (BLL) ويشير BLL إلى طبقة الوصول إلى البيانات (DAL).

أنا أستخدم عضوية مخصصة وموفر دور للترخيص.

أحاول تحديد الطبقات التي تحتاج إلى الرجوع إلى موفر العضوية الخاص بي.

في MVC، يمكنك إجراء فحوصات التفويض بالطريقة التالية:

[Authorize(Roles = "SomeRoleName")]
public ActionResult Index()
{
//do something
}

وفي BLL الخاص بي، قد أرغب في التحقق لمعرفة ما إذا كان المستخدم في دور أيضًا:

public static bool IsRoleEditor(User user, Role userRole)
  {
   bool retValue = false;

   if (user.Application.AppID == UserRole.Application.AppID)
   {
        if (Roles.IsUserInRole("ModifyRoles"))
        {
           retValue = true;
        }


    return retValue;
   }

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

نظرًا لأن لدي BLL، فهل أتجنب استخدام السمات "[Authorize(Roles = "SomeRoleName")]" وبدلاً من ذلك استدعاء دالة BLL من داخل رمز MVC للتحقق مما إذا كان المستخدم في دور ما؟إذا قمت بذلك، فسيظل MVC بحاجة إلى إشارة إلى موفر العضوية للمصادقة وعلى أي حال للاستفادة من تسجيل الدخول وعناصر تحكم ASP الأخرى، أليس كذلك؟

هل أنا بعيد عن القاعدة وأتجه في الاتجاه الخاطئ؟

Answer 1

في رأيي هذا هو ضعف العضوية / تصميم دور.

والطريقة أود أن أحصل على مدار هذا، على سبيل المثال لديك إذن المستند إلى الدور على كل من واجهة المستخدم ومستويات BLL في التطبيق ن الطبقة الموزعة، سيكون لفضح الخدمة في الدرجة BLL الذي يعرض البتات ذات الصلة (GetRolesForUser ويتم تنفيذ الخ) وعن طريق استدعاء RoleProvider على الخادم.

وبعد ذلك تنفيذ RoleProvider العرف على العميل التي يتم تنفيذها عن طريق استدعاء خدمة كشفها بواسطة BLL.

في هذه الطريقة الطبقة UI وBLL الطبقة على حد سواء يشتركان فى نفس RoleProvider. الطبقة UI يمكن استخدام المعرفة الأدوار المستخدم الحالي لتحسين واجهة المستخدم (مثل الاختباء / تعطيل عناصر التحكم UI الموافق الميزات غير مصرح بها)، وBLL يمكن ضمان أن المستخدمين لا يمكن تنفيذ منطق الأعمال التي لا يؤذن فيها.

Answer 2

والسؤال ممتاز، وسألت نفسي نفس الشيء اليوم. واحدة من فكرة كان لي (ولكن لست متأكدا إذا كان هذا هو أفضل طريقة للذهاب) هو استخدام واجهة (مثلا: IRoleProvider). يمكنك تمريرها إلى BLL لاختبار وصولك

public static bool IsRoleEditor(User user, IRoleProvider rp)
{
     return (rp.IsUserInRole(user,"ModifyRoles"));
}

مع ذلك، كنت لا تزال تحقق من وصولك في BLL الخاص بك، يمكنك استخدام وهمية في وحدة الاختبارات للتحقق مما المنطق الخاص وتحتاج فقط إلى إنشاء فئة (أو تنفيذ هذا في فئة baseController) في موقع الويب الخاص بك MVC التي ستنفذ IRoleProvider والقيام الاختيار السليم باستخدام API إذن ASP.NET.

وهذا الأمل سوف يساعد.

Answer 3

احصل على كائن المستخدم الخاص بك لتنفيذ واجهة IPrincipal ورميها حول الطبقات.ثم لا يزال بإمكانك استخدام السمة المضمنة [Autorize].

على الرغم من أنه كتب منذ أكثر من 3 سنوات عن القلعة، هذا المقال قد يساعد.يبدأ بالدخول إلى عناصر IPrincipal في منتصف الطريق.

HTHS
تشارلز

Answer 4

لماذا لم تمر الأدوار في BLL بحيث لم يكن لديك أي الاعتماد على العضوية. أو استخدام واجهة مثل MartinB المقترحة.

وماذا يحدث في المستقبل عندما صاحب الشأن الخاص بك (ق) يقرر أن يذهب مع شكلا مختلفا من التوثيق والتي لم تعد تعمل مع دور كائن؟

مثال:

IsRoleEditor(User user, string[] roles)
{
  return roles.Contains("ModifyRoles");
}

Answer 5

هل لا تغفل نقطة MVC. MVC انشقاقات من naturaly إلى طبقات. نموذج (DAL)، وحدة تحكم (BLL)، عرض (عرض). ويمكن لهذه تذهب في مشاريع مختلفة إذا كنت تحب ولكن وحدة تحكم لديه كل منطق الأعمال - تحتاج فقط للوصول إلى RoleProvider هناك

وثم تطبيق أنماط مثل مستودع، الخ نمط تقسيم الخروج مرة أخرى إذا كنت تريد.

وديفي

Answer 6

لاستدعاء وحدة تحكم MVC "UI" هي في طريقها إلى الزوال .. و'C' في MVC هو <م> الجزء من BLL الخاص بك، حتى لو كان يحيل الى الفئات التي <م> أنت سيدعو لBLL. ومع ذلك، ليس هذا هو نقطة لسؤالك.

وأنا أعتقد أن حل هذه المشكلة عن طريق طرح السؤال، "هناك حاجة حقيقية للفصل 100٪ من التطبيق" UI "وبك" BLL؟ ". إذا تشترك كل من مكونات تبعية على مقدمي عضو / الدور، ثم فليكن ذلك والحصول على العمل.

في حالة ما إذا كنت افصل BLL والمكونات في واحدة جديدة، وربما وجود تبعية مشترك على مزود. NET هو شيء يمكنك العيش معه. تعلمون أن ما يرام والتطبيق الخاص بك فقط قد لا ينهار.

وأعتقد أن الجواب جو فوق يجعل معنى كبير على الرغم من ...

Answer 7

وأعتقد أن ما تقومون به على ما يرام.

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

إذا وحدة تحكم يحدد مدير المدرسة والهوية وكنت ثم استخدام ذلك في وحدة تحكم من خلال استخدام MVC سمات فإنه يبدو وكأنه فكرة جيدة.

وسيكون من الجميل أن إخفاء موفر MVC العضوية وراء واجهة، وبهذه الطريقة يمكنك مبادلة بها لمزود WinForms عناصر العضوية (على سبيل المثال)، وسوف تكون قادرة على اختبار وحدة التحكم الخاصة بك.

Answer 8

وصول دور طبيعي لا ينبغي أن يكون في BLL. الوصول هو مسؤولية واجهة المستخدم.

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

Thread.CurrentPrincipal