SimpleMembership - किसी ने इसे एन-स्तरीय मित्रवत बनाया है?

Question

"सरलमेम्बरशिप", हमें बताया गया है, एएसपीनेट सदस्यता/भूमिका प्रबंधन का भविष्य है। एमवीसी 4 "इंटरनेट एप्लिकेशन" टेम्पलेट SimpleMembership का उपयोग कर खाता प्रबंधन लागू करता है। हालांकि, जिस तरह से इसे लागू किया गया है, सभी अनुप्रयोग स्तरों को 1

यह मुझे चौंकाने वाला है कि एमवीसी के साथ वे परतों को सही ढंग से ले जाने वाले सभी कामों के बाद, हमें "आगे बढ़ने का तरीका" "कोई डीआई के साथ सदस्यता के लिए, वेबमैट्रिक्स डीएलएल का उपयोग और एसओसी की पूरी कमी। विशेष रूप से SimpleMembershipInitialization के लिए ActionFilterAttribute - यह एक एमवीसी विशेषता से विरासत में आता है और सीधे ईएफ डीबीसीएन्टेक्स्ट को कॉल करता है।

मुझे एहसास है कि मैं आलसी हूं, लेकिन क्या किसी ने सरलमेम्बरशिप का उपयोग करके "उचित" टेम्पलेट किया है जिसका अर्थ है कि मेरे पास मेरे ऐप में उचित पृथक स्तर हो सकते हैं, और मेरे एमवीसी ऐप में ईएफ डीबीसीएन्टेक्स्ट संदर्भ नहीं हैं?

Answer 1

SimpleMembership की शक्तिशाली अवधारणाओं में से एक यह है कि आप discussed in this article के रूप में अपनी एप्लिकेशन आवश्यकताओं के अनुरूप उपयोगकर्ता प्रोफ़ाइल को कस्टमाइज़ कर सकते हैं। उदाहरण के लिए, आप add email confirmation to your registration process चाहते हैं जो उपयोगकर्ता प्रोफ़ाइल में उपयोगकर्ता के ईमेल पते को संग्रहीत करने की आवश्यकता होगी। एएसपी.नेट के लिए पिछली सदस्यता/भूमिका प्रबंधन में यह लागू करने के लिए बहुत बदसूरत था और जोड़ा गया गुण ब्लॉब में संग्रहीत किए गए थे। नीरस

तो SimpleMembership n-tier अनुकूल बनाने पर आपके प्रश्न के साथ इसका क्या संबंध है? जबकि मैं मानता हूं कि टेम्पलेट जेनरेट करता है वह एन-स्तरीय मित्रवत नहीं है, मैं यह भी कहूंगा कि किसी भी जटिलता के अधिकांश वास्तविक एमवीसी अनुप्रयोगों को सरलमेम्बरशिप को अनुकूलित करने की आवश्यकता होगी, और इसलिए एक स्तरीय या परत बनाने की आवश्यकता होगी जो वैसे भी आवेदन आवश्यकताओं के लिए विशिष्ट है। एक और तरीका बताया गया है, SimpleMembership के लिए एक पुन: प्रयोज्य स्तर बनाना केवल सबसे बुनियादी एमवीसी ऐप्स में उपयोगी होगा।

व्यक्तिगत रूप से मैं इस निष्कर्ष पर पहुंचा हूं कि सरल टेम्पलेटशिप के संबंध में इंटरनेट टेम्पलेट द्वारा जेनरेट किया गया लगभग हमेशा संशोधित किया जाएगा। first article I referenced कस्टमाइज़ेशन के पहले भाग को इंगित करता है कि SimplemembershipInitialization विशेषता से छुटकारा पा रहा है, जो कि डेवलपर फॉर्म प्रमाणीकरण का उपयोग नहीं कर रहा है, इस स्थिति में SimpleMembership को प्रारंभ करने का एक आलसी तरीका है। और अक्सर आप अपने शेष एप्लिकेशन के लिए SimpleMembership द्वारा DBContext में उपयोग किए गए DBContext को स्थानांतरित करना चाहते हैं। उपयोगकर्ता प्रोफाइल अक्सर शेष एप्लिकेशन डोमेन के साथ कड़ाई से एकीकृत होते हैं।

और चूंकि हम एसओसी और एएसपी.नेट सुरक्षा के विषय पर हैं, तो मैं तर्क दूंगा कि एएसपी.नेट इस पर कभी भी अच्छा नहीं था। प्रपत्र प्रमाणीकरण के लिए आप अपने नियंत्रकों और/या क्रियाओं पर एक प्राधिकरण विशेषता का उपयोग करते हैं जो पैरामीटर के रूप में भूमिका निभाता है। यह एप्लिकेशन डेवलपर को एप्लिकेशन डिज़ाइन को डिज़ाइन करते समय सुरक्षा डिज़ाइन के बारे में सोचने के लिए मजबूर करता है। आपको यह निर्धारित करना होगा कि आवेदन किस भूमिका के सामने होगा, और स्वर्ग मना कर देगा कि वे बाद में बदल जाएंगे क्योंकि अब आपको उन सभी विशेषताओं से गुज़रना होगा और उन्हें तदनुसार अपडेट करना होगा। मैंने एक कस्टम प्राधिकृत विशेषता का उपयोग करना शुरू कर दिया है जो एक संसाधन नाम और एक ऑपरेशन प्रकार पैरामीटर के रूप में लेता है (उदा: पढ़ें, लिखें, निष्पादित करें ...)। फिर मैं डेटाबेस में संसाधन/संचालन के लिए भूमिकाओं को मैप कर सकता हूं ताकि यह आसानी से बदल सके, या यहां तक ​​कि व्यवस्थापक को एप्लिकेशन में भूमिकाओं को कैसे लागू किया जाए, इस पर परिवर्तन करने की अनुमति दें। माइक्रोसॉफ्ट अब ClaimsPrincipalPermissionAttribute के साथ एक ही दृष्टिकोण ले रहा है कि उन्होंने WIF को .NET 4.5 में शामिल किया है।

3/8/2013

मुझे लगता है कि MVC आवेदन से SimpleMembership अलग करता CodePlex called SimpleSecurity पर एक ओपन सोर्स प्रोजेक्ट बनाया है अपडेट किया गया। आप read about it here कर सकते हैं। मुझे अभी भी लगता है कि डेवलपर संभवतः सरल सुरक्षा को संशोधित करना चाहते हैं, लेकिन चूंकि यह खुला स्रोत है। हम देखेंगे कि यह ऐसा कुछ है जिसे हम पुन: प्रयोज्य और बेहतर सरल स्मृति बनाने के लिए विकसित कर सकते हैं।

Answer 2

बिल्कुल वही जो मैं खोज रहा था (लगभग)। बस इच्छा है कि यह इकाई ढांचे में बंधे नहीं था क्योंकि मैं डैपर ओआरएम के साथ काम कर रहे केविन के एन-स्तरीय समाधान को प्राप्त करने की उम्मीद कर रहा था :(

Answer 3

स्वीकृत उत्तर सही नहीं है, यह एन-टियर नहीं है। सदस्यता डेटा पहुंच और व्यवसाय तर्क एक ही परत में हो रहा है। सिर्फ इसलिए कि कोड एक अलग असेंबली में है इसका मतलब यह नहीं है कि यह एक ही परत में नहीं है।

डेटा एक्सेस परत पर किसी प्रकार के परिवहन तंत्र के बिना, यह एन- टियर

समाधान वेबमैट्रिक्स SimpleMembershipProvider क्लास को उत्तराधिकारी और ओवरराइड करना है, जैसे कि डेटा एक्सेस कॉल अलग मेजबान पर किया जा सकता है।

मैं SimpleMembershipProvider को देखने के लिए dotPeek का उपयोग करने की सलाह देता हूं ताकि आप जान सकें कि आपके ओवरराइड में क्या करना है।

Answer 4

मुझे लगता है कि आपका प्रश्न एन-स्तरीय आर्किटेक्चर की तुलना में एसओसी से अधिक संबंधित है (जो @klatzib द्वारा बताए गए परतों के बीच भौतिक अलगाव के बारे में अधिक है)।

मैं तर्क दूंगा कि सदस्यता प्रदाताओं के भीतर तर्क व्यावसायिक तर्क के रूप में वर्गीकृत नहीं किया जाना चाहिए क्योंकि उनमें एप्लिकेशन या क्लाइंट विशिष्ट कोड नहीं है। वास्तव में प्रदाता मॉडल का विचार यह है कि यह उस संदर्भ के बावजूद एक सामान्य अनुबंध को पूरा करता है जिसमें इसका उपयोग किया जाता है। एक सामान्य गलती डेवलपर्स MembershipProvider का विस्तार कर रहा है और उच्च विशिष्ट परत में मौजूद विशिष्ट विशिष्ट तर्क तर्क में बोल्टिंग कर रहा है। यदि आप वैकल्पिक डिजाइन के साथ यही हासिल करना चाहते हैं, तो यह गलत दृष्टिकोण है। प्रदाता .NET ढांचे के लिए प्लगइन्स हैं, और कोड से पूरी तरह से सारणित किया जाना चाहिए। उन्हें निश्चित रूप से आपका आवेदन डोमेन नहीं होना चाहिए, और आपको उन्हें शायद ही कभी विस्तारित करने की आवश्यकता होनी चाहिए।

अपने प्रश्न को अन्य तरीके से संबोधित करते हुए, SimpleMembershipProvider एप्लिकेशन डिज़ाइन या यहां तक ​​कि एन-स्तरीय आर्किटेक्चर में एसओसी को प्रतिबंधित करता है? नहीं, यह नहीं करता है। एमवीसी 4 टेम्पलेट सादगी के लिए बनाया गया है, लेकिन प्रदाता प्रारंभ करने के लिए प्रयुक्त ActionFilter सदस्यता कार्यान्वयन का हिस्सा नहीं है, और आप प्रदाता को किसी भी तरह फिट करने के लिए स्वतंत्र हैं (मैं इस कॉल को डी कंटेनर फैक्ट्री से बनाना पसंद करता हूं तरीका)। वास्तव में SimpleMembershipProvider ईएफ पर कोई प्रत्यक्ष निर्भरता नहीं है, इसलिए हाँ अपने वेब ऐप में ईएफ डीबीकॉन्टेक्स्ट के संदर्भों को हटाना संभव है।