एमवीसी में विशाल नियंत्रक, या कई नियंत्रक होने के लिए बेहतर है?

Question

हम ASP.NET MVC में एक काफी बड़े मानव संसाधन आवेदन का निर्माण कर रहे हैं, और अब तक हमारे नियंत्रकों काफी बड़े होते जा रहे हैं। उदाहरण के लिए, हमारे पास कर्मचारी नियंत्रक है, और सभी कर्मचारी विचार शामिल हैं (व्यक्तिगत जानकारी, कर्मचारी कटौती, आश्रित, आदि)। इनमें से प्रत्येक विचार में कई क्रियाएं या सबव्यूव हो सकते हैं (उदा। सीआरयूडी)। प्रत्येक कार्रवाई अपेक्षाकृत छोटी है, लेकिन नियंत्रकों के दर्जनों कार्य हो सकते हैं।

वहाँ बंटवारे नियंत्रकों के लिए किसी भी सर्वोत्तम प्रथाओं हैं? इसके बजाय विचारों के दर्जनों के साथ एक कर्मचारी नियंत्रक होने के, यह बेहतर भी प्रत्येक उप-प्रकार (अर्थात EmployeePersonalInfoController, EmployeeDeductionController, EmployeeDependentController) के लिए एक नियंत्रक है हो सकता है?

और अंत में, यह और भी फर्क पड़ता है?

अपडेट किया गया स्पष्टीकरण

मेरी मूल चिंता CRUD कार्यों के साथ किया गया था। उदाहरण के लिए, EmployeeController में के बनाने और हटाने पर विचार करते हैं ...

वर्तमान कार्य:

CreateEmployee() 
    DeleteEmployee() 
    CreateEmployeeDeduction() 
    DeleteEmployeeDeduction() 
    CreateDependent() 
    DeleteDependent() 
    etc. 

तो नियंत्रकों विभाजित किया गया:

EmployeeController 
    Create() 
    Delete() 
    EmployeeDeductionController 
    Create() 
    Delete() 
    EmployeeDependentController 
    Create() 
    Delete() 
    EmployeeBenefitController 
    Create() 
    Delete() 
    etc. 

1 परिदृश्य में, हमारे ~ 100 स्क्रीन 8-10 बड़े नियंत्रकों में विभाजित हो जाते हैं। दूसरे में, शायद मेरे पास ~ 50 नियंत्रक होंगे।

Answer 1

मेरी विनम्र राय में, यदि आप अपने नियंत्रकों में कोड को नीचे रखते हैं तो यह वास्तव में कोई फर्क नहीं पड़ता।

आपका अधिकांश कोड किसी व्यापार परत में कहीं और हो रहा है? यदि ऐसा है तो आप वास्तव में अपने नियंत्रक में कर रहे हैं, डेटा को दृश्य में वापस कर रहा है। जैसा कि इसे होना चाहिए।

वास्तव में यह सुनिश्चित नहीं है कि मैं नियंत्रकों को उपप्रकारों में अलग करने का प्रशंसक हूं। जबकि आपको चिंताओं का पृथक्करण बनाए रखना चाहिए, मुझे लगता है कि उपप्रकार बहुत दूर जा रहे हैं।

आप यह पोस्ट देखने के लिए देख सकते हैं कि यह मदद करता है या नहीं। Same View Different Paths

यह आपके द्वारा सुझाए गए उप प्रकार के दृष्टिकोण का उपयोग करने से बेहतर समाधान हो सकता है।

Answer 2

नहीं क्यों उन्हें समूह?

एक संरचना है की तरह,

employee/payroll/ 
    employee/payroll/giveraise 
    employee/payroll/manage401k 

employee/general/ 
    employee/general/address 
    employee/general/emergencycontact 

अब आप एक पेरोल नियंत्रक पेरोल संबंधित क्रियाओं से निपटने और एक सामान्य नियंत्रक जो एक कर्मचारी की नियमित जानकारी के हैंडल कर सकते हैं।

Answer 3

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

यदि आपके पास बड़ी मात्रा में कोड है तो मैं सुझाव दूंगा कि आप एएसपी.नेट एमवीसी क्षेत्रों में देखेंगे।आप Here in Scott Gu's blog और Here in Steve Sanderson's blog के बारे में उत्कृष्ट पोस्ट प्राप्त कर सकते हैं। यदि आपके पास इतने सारे नियंत्रक हैं, तो यह आपके लिए उपयुक्त हो सकता है।

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

Answer 4

Partial classes आपको अपनी कक्षा को कई फाइलों में फैलाने की अनुमति देता है। इस तरह आप अपने नियंत्रक के प्रासंगिक क्षेत्रों को अलग-अलग फ़ाइलों में समूहित कर सकते हैं, और फिर भी वे सभी एक ही नियंत्रक का हिस्सा बन जाएंगे। जैसे

EmployeeDeductionController.cs

public partial class EmployeeController 
{ 
    public ActionResult Deduct() 
    { 
    } 
    // etc 
} 

EmployeeBenefitController.cs

public partial class EmployeeController 
{ 
    public ActionResult GiveBenefit() 
    { 
    } 
    // etc 
} 

Answer 5

मैं 50 नियंत्रकों के लिए नहीं करना चाहते। अभी मेरे पास 16 आवेदन हैं और यह ठीक लगता है। यदि आपके पास 50 नियंत्रक हैं तो आपके पास विचारों के लिए 50 अपूर्ण फ़ोल्डर्स भी होंगे। आपको जिस दृश्य और नियंत्रक को काम करने की आवश्यकता है उसे ढूंढना मुश्किल होगा। जैसा कि अन्य लोगों ने बताया कि कार्रवाई आम तौर पर कम होती है और यह आपके कंट्रोलर में उनमें से कुछ को खराब नहीं करती है।

मैंने सिस्टम भाग द्वारा 1 नियंत्रक होने का प्रयास किया। मैं अपनी डेटाबेस स्कीमा ले कर एक सिस्टम भाग को परिभाषित करता हूं और एक साथ संबंधित तालिकाओं के चारों ओर एक रेखा खींचता हूं।

Answer 6

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

यह भी याद रखें कि जितना संभव हो सके आपके पास अपने नियंत्रकों में कोर व्यवसाय तर्क नहीं होना चाहिए। वे वास्तव में फ्रंट एंड व्यवहार को कार्यान्वित करते हैं जबकि असली सिस्टम नियम आपके डोमेन मॉडल और सेवा परत में होना चाहिए। जब तक आप सही परत के भीतर चीजों को मोटे तौर पर रखते हैं और उचित रूप से decoupled, आप अपने नियंत्रकों के भीतर व्यक्तिगत संचालन कैसे रख सकते हैं के साथ आप बहुत गलत नहीं जा सकते हैं।

Answer 7

सीआरयूडी परिचालनों के लिए एक आम जगह में क्रॉस-कटिंग चिंताओं को रखने के लिए हम एक और दृष्टिकोण का उपयोग कर रहे हैं। यह नियंत्रक सामान्य संचालन की घोषणा करता है और विशिष्ट इकाई सामग्री के लिए एक्सटेंशन बिंदु भी शामिल करता है। हमारे पास ऐसा कुछ बिना कोड कोड डुप्लिकेशंस था।

फिर, आप इस नियंत्रक का उत्तराधिकारी बनाते हैं और प्रति इकाई बनाते हैं। और हाँ, कई नियंत्रक हैं लेकिन बहुत सी स्क्रीनें हैं, मुझे नहीं लगता कि यह मुख्य समस्या होगी।

अधिकांश क्रियाएं जटिल मॉडल स्वीकार करती हैं और हम नियंत्रक से अव्यवस्था को हटाने के लिए मॉडल बाइंडर्स के साथ खेलते हैं। आप here के बारे में एक अच्छी पोस्ट देख सकते हैं।

फिर, @Odd सुझावों जैसे क्षेत्रों का उपयोग करना एक अच्छा विचार है, कम से कम विचारों को अलग करना क्योंकि जब आपके पास उनमें से बहुत कुछ गड़बड़ है।

उम्मीद है कि एएसपी।नेट एमवीसी वी 2 हमें विभिन्न विधानसभाओं में क्षेत्रों को लाएगा और विचारों को समाहित करेगा (वास्तव में वर्चुअलपाथप्रोवाइडर क्लास को विस्तारित किया जा सकता है)।