क्या आपके पास UserId की आवश्यकता होने पर हर बार डेटाबेस कॉल सहेजने का आपका कारण है? यदि ऐसा है, तो जब मैं ASP.NET सदस्यता प्रदाता का उपयोग कर रहा हूं, तो मैं आमतौर पर एक कस्टम प्रदाता करता हूं जो मुझे उस कॉल को कैश करने की अनुमति देता है, या एक उपयोगिता विधि जिसे मैं कैश कर सकता हूं।
यदि आप इसे प्रोफ़ाइल में डालने की सोच रहे हैं, तो मुझे ऐसा करने के लिए बहुत अधिक कारण नहीं दिख रहा है, विशेष रूप से इसे अभी भी एक डेटाबेस कॉल की आवश्यकता होगी और जब तक कि आप एक कस्टम प्रोफ़ाइल प्रदाता का उपयोग नहीं कर रहे हैं, UserId को पार्स करने की अतिरिक्त प्रसंस्करण।
यदि आप सोच रहे हैं कि उन्होंने GetUserId विधि को क्यों लागू नहीं किया है, तो यह केवल इसलिए है क्योंकि आप हमेशा गारंटी नहीं देते हैं कि वह उपयोगकर्ता आईडी शामिल प्रदाता में GUID होगा।
संपादित करें:
देखें ScottGu's article on providers जो एक link to downloading the actual source code for i.e. SqlMembershipProvider प्रदान करता है।
लेकिन वास्तव में करने के लिए सबसे आसान चीज आपके उपयोगकर्ता ऑब्जेक्ट या यूटिलिटी क्लास में GetUserId() विधि है, जहां आपको उपयोगकर्ता आईडी को कैश/सत्र से मिलता है, अन्यथा डेटाबेस को हिट करें, उपयोगकर्ता नाम (या स्टोर द्वारा कैश करें) सत्र में), और इसे वापस करें।
अधिक कुछ पर विचार करें (लेकिन क्योंकि कुकी आकार प्रतिबंध के बहुत सावधान रहना होगा) के लिए: Forms Auth: Membership, Roles and Profile with no Providers and no Session
क्या आप इस कारण से विस्तार कर सकते हैं? – Kev
जब मैं सदस्यता। GetUser() को कॉल करता हूं। ProviderUserKey को हर बार इस उपयोगकर्ता आईडी – GrZeCh