2009-01-01 16 views
28

नियंत्रक से मॉडल में तर्क को स्थानांतरित करना अच्छा अभ्यास है। लेकिन किसी भी जटिल प्रणाली में, यह हमेशा एक बहुत बड़ी फाइल की ओर जाता है भले ही अधिकांश तरीके रेलवे वे के अनुसार एक लाइनर हैं।रेल पदार्थ मॉडल को व्यवस्थित करने के लिए जो बहुत मोटा हो?

मैंने मॉडल को अन्य मॉड्यूल में विभाजित करने और मूल मॉडल में उन्हें शामिल करने का सहारा लिया है, उदाहरण के लिए, model_flags, model_validation, आदि। किसी के पास बेहतर तरीका है?

संपादित करें: मैंने एक नया उत्तर चुना है जो ActiveConcern का उपयोग करने का सुझाव दिया गया है। साथ ही, कोड को व्यवस्थित करने में रुचि रखने वाले किसी भी व्यक्ति के लिए, यह आलेख, Making ActiveRecord Models Thin, बहुत मदद करनी चाहिए।

उत्तर

28

मैं यह एहसास एक काफी पुराना सवाल है और इसे उत्तर के रूप में चिह्नित किया गया है, लेकिन मुझे लगता है कि यह अभी भी अच्छा Google रस है, इसलिए मुझे लगा कि यह जोड़ने के लायक था ...

रेल 3 ने सक्रिय समर्थन :: कंसर्न पेश किया, जिसे व्यवहार को मॉड्यूलर करने के लिए उपयोग किया जा सकता है यह मॉडल भर में साझा किया जाता है। या, उस मामले के लिए, उन मॉडलों को पतला करने के लिए जो बहुत मोटा हो गए हैं।

DHH खुद यहाँ एक अच्छा, संक्षिप्त उदाहरण सार प्रदान करता है:

https://gist.github.com/1014971

+1

मैंने रेड डॉट रूबी सम्मेलन (मुझे ग्रेग पोलैक से विश्वास है) से इसके बारे में सीखा, इसलिए हाँ मुझे विश्वास है कि आगे बढ़ना, यह एक बेहतर तरीका है, जो रेल कोर के साथ अच्छी तरह से खेलता है। – Jaryl

+0

एक नोट: शब्दावली (मामले का, जवाब नहीं) भ्रमित होने के समाप्त हो गया। 'ActiveSupport :: Concern' का उपयोग पुन: प्रयोज्य कोड (कई मॉडलों द्वारा) के साथ मॉडल लिखने के लिए किया जाता है, जबकि पैटर्न 'related_with' एक मॉडल को टुकड़ों में विभाजित करने का एक आसान तरीका है। मुझे पहले पसंद है (क्योंकि यह ऐप/lib के बदले ऐप का उपयोग करने के लिए निर्देशित करता है) और मुझे दूसरे के बारे में निश्चित नहीं है (यह सुविधाजनक लेकिन अवधारणात्मक संदिग्ध लगता है)। – tokland

+2

मुझे लगता है कि यह सोचने लायक है कि मॉडल मोटापे को संबोधित करने के लिए चिंताओं का एक तरीका है। Srboisvert नोट्स के रूप में, किसी मॉडल को चिंताओं में विभाजित करने से पहले अपने ऑब्जेक्ट डिज़ाइन पर सवाल करना एक अच्छा विचार है। यहां एक आलेख है जो चर्चा करता है: http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/ – tjstankus

0

मॉड्यूल समझदार लगता है। मैं विधि कॉल (सत्यापन, कॉलबैक, प्लगइन्स इत्यादि) मॉड्यूल में निकालेगा, हालांकि, मैं अपने स्वयं के तरीकों के निष्कर्षण को सीमित कर दूंगा।

और हमेशा के रूप में, यदि आप कुछ नमूना कोड पोस्ट करते हैं तो यह मदद करेगा। मुझे मॉडलों को साफ करने के लिए एक सामान्य रणनीति की कल्पना करना मुश्किल लगता है, यह कोड की प्रकृति पर निर्भर करता है।

+0

ठीक है, यह बात है; मेरे पास वास्तव में कोई रणनीति नहीं है। वर्तमान में, मैं बस फाइल से दूसरे में विधियों को डंप कर रहा हूं, जो बहुत रेल-एश महसूस नहीं कर रहा है, यही कारण है कि मैं यह जानने के लिए यहां हूं कि सबसे अच्छा अभ्यास क्या है। चीयर्स =) – Jaryl

5

मैं कुछ कारणों से ऐसा नहीं करता।

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

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

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

+1

रेल में अधिकांश व्यवहार 'वे कहाँ होना चाहिए' नहीं मिल सकते हैं। इसके अलावा, मुख्य मॉडल फ़ाइल में मॉड्यूल को शामिल करके, आप पहले ही कह रहे हैं कि कहां देखना है। मैं मानता हूं कि बड़ी फ़ाइलों को नेविगेट करना मुश्किल नहीं है, लेकिन आप अपने मॉडल को कैसे विभाजित करते हैं? किस प्रकार की विधियां पहले जाती हैं? – Jaryl

+0

मैं अपने मॉडल को विभाजित नहीं करता हूं। मैं कार्यक्षमता और वर्णानुक्रम से उन्हें व्यवस्थित करने के बीच खाली हो जाता हूं लेकिन मुझे इसके बारे में बहुत चिंता नहीं है। मैं नाकाजीमा से सहमत हूं कि आपको जहां संभव हो, साझा और पुन: प्रयोज्य कार्यक्षमता को खींचना चाहिए, लेकिन डीआरवाई के लिए और लंबाई से अच्छी डिजाइन के लिए अधिक। – srboisvert

+0

जैसा कि मैंने अपने उत्तर के लिए एक टिप्पणी में नोट किया है, मुझे लगता है कि यह एक वैध बिंदु है, विशेष रूप से अंतिम अनुच्छेद। ऑब्जेक्ट डिज़ाइन की बात आती है जब कुछ भी कट और सूखा नहीं होता है। अपने डिजाइन अक्सर पूछें और अपना सर्वश्रेष्ठ निर्णय लें। – tjstankus

1

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

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

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

4

ठीक है, मैं यह नहीं कहूंगा कि आप में से कोई भी एक मॉडल में सबकुछ रखना गलत है, लेकिन मुझे लगता है कि यह विभिन्न चिंताओं को अलग करने में सक्षम होने के लिए भी मान्य है। यह कम से कम एक व्यापार बंद है।

और मैं, मेरे अपने प्रश्न का उत्तर पोस्ट कर रहा हूँ के रूप में मैं सिर्फ इतना है कि ऐसा करने के लिए रेल मार्ग मिल गया है: http://github.com/jakehow/concerned_with

अधिक जानकारी यहां पाया जा सकता है: http://m.onkey.org/2008/9/15/active-record-tips-and-tricks

संबंधित मुद्दे