लंबे नामों से बचने के लिए दृश्य मॉडल के बारे में नामकरण सम्मेलन

Question

मैं बना रहा हूं, मेरे एएसपी.नेट एमवीसी अनुप्रयोग में प्रत्येक स्क्रीन के लिए मॉडल देखें। मैंने बिल्डर कक्षा में एक दृश्य मॉडल बनाने के लिए सभी तर्क डाले। आम तौर पर, समेकित, फ़िल्टरिंग और सॉर्टिंग सहित डेटा ऑब्जेक्ट्स को देखने के लिए डेटा ऑब्जेक्ट्स को परिवर्तित करने के लिए विशेष तर्क होता है। प्रत्येक निर्माता को निर्भरता सेट पारित किया जाता है, जो एक वस्तु है जिसमें प्रत्येक निर्भरता (भंडार, अन्य बिल्डर्स इत्यादि) के गुण होते हैं।

समस्या यह है कि मेरे नाम वास्तव में लंबे हो रहे हैं। एक निर्भरता सेट आमतौर पर एक नाम इस तरह से बना होगा:

दृश्य-मॉडल-नाम + बिल्डर + DependencySet

देखें मॉडल आमतौर पर जहां आप वर्तमान में कर रहे हैं और बच्चों से बना नाम है। उदाहरण के लिए, मेरे सिस्टम ने प्रदाता परिभाषाओं को वर्गीकृत किया है। तो, आदेश में एक श्रेणी के अंतर्गत प्रदाता परिभाषाओं को दिखाने के लिए, मैं कहा जाता है एक दृश्य मॉडल है:

CategoryProviderDefinitionListViewModel

वह कुछ इस तरह दिखेगा:

public sealed class CategoryProviderDefinitionListViewModel 
{ 
    public long CategoryId { get; set; } 
    public string CategoryName { get; set; } 
    public ProviderDefinitionViewModel[] ProviderDefinitions { get; set; } 
} 

तो, मेरी बिल्डर को

श्रेणीप्रोवाइडरडिफिशनलिस्टव्यूमोडेलबिल्डर

तो, मेरी निर्भरता सेट कहा जाता है

CategoryProviderDefinitionListViewModelBuilderDependencySet

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

आदर्श रूप में, मैं अपने दृश्य मॉडल कक्षाओं को एक साथ समूहित कर सकता हूं, उन्हें उन दृश्यों (एस) के साथ जोड़कर जहां उनका उपयोग किया जाता है। टकराव से बचने और नाम को कम से कम नाम बनाने के लिए अच्छा होगा, जबकि उन्हें सार्थक बनाए रखा जाए। क्या किसी ने नामकरण सम्मेलन/फ़ोल्डर संगठन पाया है जो इस परिदृश्य में अच्छी तरह से काम करता है?

Answer 1

मैं थोड़ी देर के लिए लगातार "व्यूमोडेल" प्रत्यय का उपयोग कर रहा हूं और ईमानदार होने के लिए, कभी-कभी मुझे इसे अनावश्यक लगता है। मुझे लगता है कि इन सभी वर्गों को एक अलग नामस्थान में समूहित करना पर्याप्त होना चाहिए।

मेरे समझ है कि इस सम्मेलन डोमेन मॉडल और देखने मॉडल वर्गों के बीच टकराव से बचने के लिए (जैसे उत्पाद बनाम ProductViewModel) को अपनाया गया है। हालांकि, चूंकि आपके व्यू मॉडल का नाम स्क्रीन के नाम पर रखा गया है, इसलिए यह बहुत संभावना नहीं है कि आपके पास अपने डोमेन मॉडल में एक ही नाम वाला क्लास होगा। वास्तव में, यह वास्तव में संदिग्ध होना चाहिए कि आपके डोमेन मॉडल में ऐसी कक्षा क्यों है!:)

इसलिए, यदि आप ViewProduct की तरह आपके विचार मॉडल कुछ ही नाम (उपयोगकर्ता देखने/एक उत्पाद को संपादित करने की अनुमति देने के लिए), आप इसे ViewProductViewModel कॉल करने के लिए की जरूरत नहीं है। देखो मैं कहाँ जा रहा हूँ?

नतीजतन, आपके बिल्डर वर्ग बस ViewProductBuilder बजाय की ViewProductViewModelBuilder कहा जा सकता है।

आपके निर्भरता सेट के संबंध में, मुझे यकीन नहीं है कि इसके पीछे आपका तर्क क्या है। लेकिन मेरे लिए यह अनावश्यक दिखता है। यदि आपके निर्माता के पास अन्य ऑब्जेक्ट्स पर निर्भरता है, तो आपको किसी अन्य वर्ग (निर्भरतासेट) में encapsulating और फिर उन्हें चारों ओर गुजरने के बजाय, निर्माता के निर्माता में निर्भरता इंजेक्षन करने की आवश्यकता होगी।

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

आशा इस मदद :)

Answer 2

मैं "डीटीओ" के साथ मेरी ViewModel नाम के बाद फिक्सिंग पसंद करते हैं। (जहां डीटीओ डेटा ट्रांसफर ऑब्जेक्ट के लिए खड़ा है, यानी एक ऑब्जेक्ट जिसमें कुछ भी नहीं है लेकिन इसमें जानकारी है)

यह केवल लंबे नामों से बचने के लिए नहीं है। लेकिन यह मुझे उपयोगकर्ता जैसे नामों का उपयोग करने में सक्षम बनाता है, लेकिन इसे उपयोगकर्ता डीटीओ कहा जाएगा, जो मुझे इंगित करता है कि मैं एक ऐसे ऑब्जेक्ट के साथ काम कर रहा हूं जो मेरे व्यूमोडेल का हिस्सा है, और इस प्रकार टकराव नामकरण से बचें।

Answer 3

मैं मोश से सहमत हूं।

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

बेशक आपके प्रस्तुतकर्ता/नियंत्रक में आप टकराव नामकरण कर सकते हैं, लेकिन यह एक संकेत हो सकता है कि आपको अपने विचारों को अधिक उचित रूप से नामित करने की आवश्यकता है, उदा। उपयोगकर्ता नहीं, लेकिन ViewUser/EditUser।

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