2009-07-09 16 views
8

मैं एनएचबीनेटनेट का उपयोग कर एक बहुत ही बुनियादी एएसपी.नेट एमवीसी ऐप का मॉडल कर रहा हूं और मुझे लगता है कि मैं अपने डिजाइन पर फंस गया हूं। यहाँ मेरी मॉडल की एक संक्षिप्त वर्णन है:क्या मैं अपनी कुल सीमाओं को तोड़ रहा हूं?

model 1 http://i29.tinypic.com/309614n.jpg

आप देख सकते हैं यह बहुत ही बुनियादी है, लेकिन मैं इस बारे में कुछ चिंताएं हैं। उपयोगकर्ता रूट इकाई और संगठन रूट इकाई एक ही संगठन_यूसर इकाई बच्चे को दो-से-कई रिश्तों के माध्यम से एक्सेस कर रही है। यह सही प्रतीत नहीं होता है और मुझे लगता है कि मैं कुल सीमाओं को तोड़ रहा हूं। यह मॉडल मेरे लिए खुशबू आ रही है, लेकिन मैं विचार पसंद है क्योंकि मैं इस तरह कोड करना चाहते हैं:

var user = userRepository.Load(1); 
var list = user.Organizations; // All the organizations the user is a part of. 

और

var org = orgRepository.Load(1); 
var list = org.Users; // All the users in an organization. 

इसके अलावा अतिरिक्त की तरह तालिका में डेटा चिह्नित किए जाने और भूमिका के द्वारा इस्तेमाल किया जाएगा संगठन इकाई। क्या यह एक खराब डिजाइन है? यदि आपके पास कोई विचार है जो बहुत अच्छा होगा। मैं अभी भी डीडीडी की सोच के आसपास अपना मन पाने की कोशिश कर रहा हूं। धन्यवाद

उत्तर

2

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

var user = userRepository.Load(1); 
var list = user.OrganizationUsers; // All the organizations the user is a part of including their role and flagged values. 

var organization = list[0].Organization; 

* आप सभी एक उन संगठनों के माध्यम से पुनरावृत्ति होने के लिए अक्सर आप उत्सुक लोड करने के लिए OrganzitionUser

के साथ संगठन इकाई दूसरे डिजाइन के साथ होने की संभावना चाहते हैं जा रहे हैं आप सबमिट किया गया ऐसा लगता है कि आप OrgUserDetails पर उपयोगकर्ता को संगठन उपयोगकर्ता पर उपयोगकर्ता को जोड़ने के बिना उपयोगकर्ता को जोड़ने में सक्षम होंगे। यह ऐसा कुछ प्रतीत नहीं होता है जिसे मैं अपने डोमेन से समर्थन देना चाहता हूं।

+0

आपके उत्तर के लिए बहुत बहुत धन्यवाद। यह सही तरीका है कि मैं इस मॉडल को लागू करना चाहता हूं। आपने एक महान बिंदु लाया है कि उसी जानकारी के साथ OrgUserDetails और OrganizationUser को अपडेट करना इतना अच्छा विचार नहीं है। मैं अपने पहले मॉडल के साथ जा रहा हूं और संगठन यूजर क्लास को जोड़ रहा हूं, जैसा आपने कहा था, मेरे संगठन डोमेन में ताकि मैं उन अतिरिक्त विशेषताओं तक पहुंच सकूं। ऐसा लगता है कि ठीक काम करेगा। आपकी सहायता के लिए एक बार फिर से धन्यवाद! – CalebHC

4

यह एक आम तौर पर कई से अधिक रिश्ते हैं। और संगठन_उसर टेबल पुल तालिका है। असर एनएचबीर्नेट और अन्य सभी ओआरएम टूल्स में ब्रिज टेबल का समर्थन करने के लिए अंतर्निहित सुविधा है।

यह चीज़ आवेदन स्तर के बजाय डेटा मॉडलिंग स्तर पर हल की जानी चाहिए। आपको अपने डेटा मॉडल का विश्लेषण करना चाहिए और कई से अधिक रिश्तों से बचने के लिए अनुशंसा की जाती है (अर्थात् यदि यह डोमेन मॉडल की नीचीता नहीं है, तो आपको कई से अधिक रिश्ते से बचने की कोशिश करनी चाहिए)।

सबसे पहले आपको यह सुनिश्चित करने की आवश्यकता है कि डोमेन इकाइयों को मैप करने के लिए डेटा मॉडल में कई से अधिक संबंध आवश्यक हैं। एक बार जब आप ऐसा करते हैं तो किया है मॉडल अपने चित्र में प्रतिनिधित्व किया

2

पहले चीजों आवेदन स्तर पर उन रिश्तों मानचित्रण DDD में विचार करने के लिए ठीक है कर रहे हैं:

  • अपने डेटाबेस स्कीमा भूल (वहाँ कोई डेटाबेस!)
  • डोमेन परिप्रेक्ष्य से थोज़ इकाइयों पर आप कौन सी कार्रवाइयां करेंगे?
+1

जब तक आप प्रदर्शन समस्याओं को हिट नहीं करते हैं और फिर आपको खेद है कि आप डेटाबेस के बारे में भूल जाते हैं :) –

1

मेरे समझ है:

एक उपयोगकर्ता 0-से-अनेक संगठनों की हो सकती है। और एक संगठन में 0 से कई उपयोगकर्ता होते हैं।

क्या वे दोनों सही हैं? यदि ऐसा है, तो यह मेरे लिए बहुत से लोगों की तरह लगता है।

कई से अधिक लोगों में, आपको उस अंतर को पुल करने के लिए किसी तरह के रिश्ते जैसी वस्तु की आवश्यकता होती है। समस्या यह है कि डोमेन में कोई उपयोगकर्ता_ऑर्गनाइजेशन नहीं है।

इससे मुझे लगता है कि आपके उपयोगकर्ता के हिस्से के रूप में उपयोगकर्ता_ऑर्गनाइजेशन नहीं होना चाहिए, प्रति से। यह एक कार्यान्वयन विस्तार की तरह लगता है।

दूसरी तरफ, हो सकता है कि आपके डोमेन में रोस्टर हो, जो संगठन में उपयोगकर्ताओं को रखता है और उनकी भूमिका और उस संबंध के लिए विशिष्ट अन्य जानकारी संग्रहीत करता है।

2

मुझे लगता है कि आपका मॉडल ठीक है।मैं आमतौर पर डोमेन की कुल जड़ों के बारे में सोचता हूं, जब मैं उनके बारे में सोचता हूं, सार्वजनिक रूप से उजागर होने के संदर्भ में, आंतरिक कार्यान्वयन नहीं। संबंधों के साथ मुझे लगता है कि संबंध में कौन सी इकाई "पैंट पहनती है"। यही है, क्या किसी उपयोगकर्ता को किसी उपयोगकर्ता को जोड़ना या उपयोगकर्ता को संगठन जोड़ना अधिक स्वाभाविक है? इस मामले में दोनों समझ सकते हैं, उपयोगकर्ता एक संगठन में शामिल हो जाता है; एक संगठन सदस्यता के लिए एक उपयोगकर्ता स्वीकार करता है।

यदि आपका डोमेन उपयोगकर्ता के परिप्रेक्ष्य से संबंध देखता है, तो आप उपयोगकर्ता पर संबंध बनाए रखने (जोड़ने, निकालने, आदि) को बनाए रखने के लिए विधियों को डाल सकते हैं और संगठन पर केवल पढ़ने के लिए संग्रह का पर्दाफाश कर सकते हैं।

आपके दूसरे डिज़ाइन के जवाब में (यदि आपने मूल प्रश्न संपादित किया होगा तो बेहतर होगा): मुझे यह बिल्कुल पसंद नहीं है। आपका मूल डिजाइन ठीक है। मैं आपकी कक्षाओं को डिजाइन करते समय डेटाबेस को अनदेखा नहीं करता, एक अच्छा डिज़ाइन सटीक रूप से डोमेन का मॉडल करना चाहिए और एक संबंधपरक डेटाबेस में लागू करने के लिए सीधा होना चाहिए। कभी-कभी आपको मीठे स्थान पर हिट करने के लिए दोनों दिशाओं में समझौता करना पड़ता है। कुल सीमाओं को तोड़ने के लिए कोई जेल की अवधि नहीं है। :-)

+0

आपके इनपुट के लिए धन्यवाद। हाँ, अब मैं उस दूसरे डिजाइन को देखता हूं, मुझे वास्तव में यह पसंद नहीं है! :) – CalebHC

0

आपके उत्तरों के लिए सभी को धन्यवाद। वे बहुत उपयोगी रहे हैं।

जबकि मैं अपने मॉडल के बारे में कुछ और सोच रहा था, मैंने कुछ नया स्केच किया जो मुझे लगता है कि बेहतर होगा।

alt text http://i26.tinypic.com/ic0pw4.png

मेरे सोच यह थी:

  1. जब साइट प्रणाली अपने अकाउंट पाता है और उसके बाद में किसी उपयोगकर्ता के लॉग संगठनों वे के अलावा हैं की एक सूची देता है और इसे से यह जानकारी हो जाता है user_organizations ऑब्जेक्ट।

  2. जब कोई उपयोगकर्ता संगठनों में से किसी एक पर क्लिक करता है तो वे इसके अलावा संगठन के नियंत्रण कक्ष में निर्देशित होते हैं।

  3. चयनित संगठन तब उस संगठन की भूमिका को देखता है जो उस संगठन को नियंत्रित करता है ताकि उपयोगकर्ता को उस संगठन को नियंत्रित करने के लिए उपयोगकर्ता के पास क्या पहुंच हो।

क्या यह समझ में आता है? :)

मुझे लगता है कि यह मॉडल में अच्छा होगा लेकिन मुझे डीबी कार्यान्वयन के बारे में कुछ संदेह हैं। मुझे पता है कि मुझे इसके बारे में भी चिंता नहीं करनी चाहिए, लेकिन मैं अभी तक अपनी बुरी आदत नहीं तोड़ सकता! आप देख सकते हैं कि user_organizations ऑब्जेक्ट और org_user_details ऑब्जेक्ट में डुप्लिकेट डेटा है। मैं एक डीबी समर्थक नहीं हूं लेकिन क्या यह एक खराब डीबी डिजाइन है? क्या मुझे इसके बजाय उपयोगकर्ता_ऑर्गनाइजेशन और org_user_details से डेटा को मेरी पहली पोस्ट में से एक तालिका में जोड़ना चाहिए और केवल एनएचबीर्नेट को बताएं कि उपयोगकर्ता इसे कई से अधिक रिश्ते के रूप में देखता है और संगठन इसे एक से कई रिश्तों के रूप में देखता है ? ऐसा लगता है जैसे मैं सिस्टम को धोखा दे रहा हूं। क्षमा करें अगर मैं इस बारे में वास्तव में उलझन में लग रहा था।

इस पर आपके विचार क्या हैं? क्या मैं यह सोच रहा हूँ? : पी

+1

ऑफ-विषय लेकिन मैं इसका विरोध नहीं कर सकता ... आप किस चित्र को चित्रित करने के लिए उपयोग करते हैं? – MatthieuGD

+0

लॉल, कोई समस्या नहीं। मैं एक तीक्ष्ण ठीक बिंदु कलम का उपयोग कर रहा था। मैंने सोचा कि यह चित्र लेने के लिए अच्छा दिखाएगा। मुझे लगता है कि यह ठीक काम किया। कक्षा या यूएमएल आरेख के रूप में उतना अच्छा नहीं है! :) – CalebHC