لماذا يجب على موفر العضوية الأساسي أن يقرر ما إذا كان...؟

Question

أ) لماذا، عند استخدام القوالب مع معالج إنشاء المستخدم السيطرة، لا بما في ذلك مربع الكتابة مع المعرف=البريد الإلكتروني تعتمد على ما إذا كان CreateUserWizard.RequireEmail تم تعيين الخاصية على true، ولكن مربع الكتابة مع المعرف=سؤال مطلوب فقط إذا كان موفر العضوية الأساسي يتطلب سؤال كلمة المرور؟بمعنى آخر، لماذا لا يكون الأمر متروكًا أيضًا لمزود العضوية الأساسي ليقرر ما إذا كان ذلك أم لا مربع الكتابة ( بالمعرف=البريد الإلكتروني ) مطلوب؟

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

ثانكس

يحرر:

أ)

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

لذا فإن RequiresUniqueEmail يخبرنا في جوهره أنه لا يتعين على المستخدم تحديد عنوان بريد إلكتروني، ولكن إذا فعل ذلك، فيجب أن يكون فريدًا؟

ب)

• إذا فهمت مقدمي العضوية بشكل صحيح، فهي الجهات التي ترسل استعلامات SQL لتخزين البيانات؟!وبالتالي أفترض أن لديهم المعرفة الكاملة بالجداول والعلاقات وما إلى ذلك الذي يمتلكه تخزين البيانات هذا؟

• ولكن مع ذلك، ماذا لو لم يكن مخزن البيانات يحتوي على عمود لتخزين عناوين البريد الإلكتروني، ولكن CreateUser() يحدد عنوان البريد الإلكتروني كأحد معلماته؟كيف يتعامل مزود العضوية مع ذلك؟

Answer 1

ومن المثير للاهتمام أن البريد الإلكتروني جزء من حقول البيانات المتوقعة.

اسمحوا لي أن أوضح...إذا قمت بتعيين RequiresUniqueEmail على true لموفر SQL، فلن يكون البريد الإلكتروني مطلوبًا - بالمعنى الدقيق للكلمة.هذا يعني فقط أنه سيتعين على كل مستخدم استخدام عنوان بريد إلكتروني مختلف عن أي مستخدم آخر.لذلك يمكن أن يكون هناك مستخدم واحد بدون عنوان بريد إلكتروني.سيتم تعيين قيمة فارغة في قاعدة البيانات.ولكن لن يتمكن أي مستخدم آخر من حذف عنوان البريد الإلكتروني بعد ذلك لأن ذلك سيؤدي إلى حصول مستخدمين على رسائل بريد إلكتروني فارغة...لذلك، من الناحية الوظيفية، قد تكون هي نفس عناوين البريد الإلكتروني المطلوبة، ولكنها ليست هي نفسها من الناحية الفنية.

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

أما بالنسبة لفهم نظام العضوية نفسه ...

يعد نظام العضوية في asp.net بمثابة حل وسط بين تصميم OO الصارم والراحة.توجد بعض الافتراضات في فئة MembershipProvider الأساسية التي يرث منها موفرو العضوية المحددون، وهي افتراضات.حقيقة أن عناوين البريد الإلكتروني ستكون جزءًا من بيانات العضوية هي واحدة من الافتراضات الأكثر ليبرالية التي يقدمها المزود الأساسي.

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

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

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

Answer 2

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

تحديد أنه يجب عليهم توفير عنوان بريد إلكتروني فريد يتطلب بريدًا إلكترونيًا فريدًا ليس مثل قول "يتطلب بريدًا إلكترونيًا" - لذا فإن CreateUserWizard يقدم لك خيار قول "لا يهمني أن عناوين البريد الإلكتروني ليست فريدة، فقط أن هناك واحدًا".

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

تعتمد فئة العضوية على موفري العضوية للتواصل مع مصدر البيانات.

---

ردا على تعديلات السؤال:

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

ب.1.ليس تمامًا - يرسل الموفرون البيانات من وإلى مخزن بيانات المستخدم الخاص بك - قد يكون هذا SQL، ولكن يمكن أيضًا أن يكون Active Directory، أو LDAP، أو ملفًا نصيًا، وما إلى ذلك، ولكن نعم، يعمل الموفر الخاص بك كطبقة فصل بين تطبيقك و متجر المستخدم الخاص بك.

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