एकाधिक मॉडलों के साथ एक नियंत्रक? क्या मैं यह सही ढंग से कर रहा हूँ?

Question

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

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

तो वित्तीय टैब मूल रूप से दो मॉडल से डेटा के साथ काम करेगा: लेनदेन और बैंक_काउंट। मुझे लगता है कि मैं मॉडल (लेनदेन & bank_accounts) बनाना चाहिए और फिर एक नियंत्रक वित्तीय कहा जाता है, तो मैं मॉडल वित्तीय नियंत्रक से क्वेरी कर सकते हैं और एप्लिकेशन/विचारों/वित्तीय में पृष्ठों को प्रदर्शित/

मैं सही हूँ इस ऐप लेआउट में? मैंने कभी मचान की मूल बातें से अधिक काम नहीं किया है, इसलिए मैं यह सुनिश्चित करना चाहता हूं कि मुझे यह अधिकार मिल जाए!

धन्यवाद!

Answer 1

आप मचान के साथ आराम कर रहे हैं तो मैं सुझाव है कि आप दोनों

लेनदेन के लिए एक पाड़ उत्पन्न: script/generate scaffold transaction financial_id:integer ...

bank_accounts: script/generate scaffold bank_account financial_id:integer ...

और वित्तीय script/generate scaffold financials ...

अपने लेनदेन मॉडल में , इसे जोड़ें:

class Transaction < ActiveRecord::Base 
    belongs_to :financial 
end 

अपना BANK_ACCOUNT मॉडल में, इस जोड़ें: नियंत्रक आप कुछ इस तरह उपयोग कर सकते हैं अपने वित्तीय से

class Financial < ActiveRecord::Base 
    has_many :transactions 
    has_many :bank_accounts 
end 

अब:

def index 
    @financial = Financial.find(params[:id]) 

    #This fetches all bank_accounts related to financial 
    @bank_accounts = @financial.bank_accounts 

    #This fetches all transactions related to financial 
    @transactions = @financial.transactions 
end 

class Bank_account < ActiveRecord::Base 
    belongs_to :financial 
end 

अपने वित्तीय मॉडल में, इस ऐड

अपने विचारों में आप यह कर कर किसी विशेष वित्तीय से संबंधित सभी बैंक खाते देख सकते हैं:

<% @bank_accounts.each do |bank_account| -%> 
    <%=h bank_account.something_here %> <!-- something_here is the column name corresponding to your bank_account table. --> 
    <%=h bank_account.something_here %> <!-- something_here is the column name corresponding to your bank_account table. --> 
    <%=h bank_account.something_here %> <!-- something_here is the column name corresponding to your bank_account table. --> 
    . 
    . 
    . 
<% end -%> 

अपने विचार में आप कुछ इसी तरह जोड़कर सभी एक विशेष वित्तीय लेन-देन से संबंधित देख सकते हैं: जबकि बनाने एक नया लेन-देन/BankAccount आईडी विशेष वित्तीय से संबंधित का उपयोग करें,

<% @transactions.each do |transaction| -%> 
    <%=h transaction.something_here %> <!-- something_here is the column name corresponding to your bank_account table. --> 
    <%=h transaction.something_here %> <!-- something_here is the column name corresponding to your bank_account table. --> 
    <%=h transaction.something_here %> <!-- something_here is the column name corresponding to your bank_account table. --> 
    . 
    . 
    . 
<% end -%> 

याद रखें । उम्मीद है की यह मदद करेगा। चीयर्स! :)

Answer 2

मेरे पास रेल पर रूबी या सामान्य रूप से एमवीसी काम के साथ बहुत अधिक अनुभव नहीं है, लेकिन मुझे लगता है कि आप इसके बारे में सही तरीके से जा रहे हैं। डेटा-उन्मुख संसाधनों के लिए आप आम तौर पर एक मॉडल ऑब्जेक्ट (और विस्तार, डेटाबेस तालिका) चाहते हैं ... यानी, आपके मॉडल आपके "संज्ञाओं" से मेल खाते हैं। आपके नियंत्रक के कार्य आपके "क्रियाएं" हैं, और मेरे लिए यह उन्हें वर्गीकृत करने के लिए सही अर्थ बनाता है कि आप कैसा पसंद करते हैं।

इस मामले में, मैं कहूंगा कि financials के तहत "क्रियाएं" का एक गुच्छा डालना, जो आवश्यकतानुसार दो मॉडल ऑब्जेक्ट प्रकारों के साथ बातचीत करता है, अगर मुझे लगता है और केवल अगर यह आपके लिए इसे व्यवस्थित करने के लिए आपको समझ में आता है । (ध्यान रखें कि आप यह भी मूल्यांकन कर सकते हैं कि संबंधित यूआरएल आपको कितने अच्छी तरह संगठित और अंतर्ज्ञानी महसूस करते हैं, हालांकि मुझे यकीन है कि अधिकांश एमवीसी purists जोड़ देंगे कि आपको कभी भी यूआरएल की जांच करने पर भरोसा नहीं करना चाहिए!)

तो संक्षेप में , मुझे लगता है कि आप यहां सब कुछ कर रहे हैं, जब तक यह आपको समझ में आता है। हां, आपको अपने विचार और नियंत्रक कार्यों को स्वयं लिखना होगा, हालांकि आप ruby script/generate controller financials action1 action2 [...] का उपयोग शुरू कर सकते हैं; कि कम से कम आपको दृश्य फ़ाइलों और खाली नियंत्रक कार्यों के कंकाल देता है।

Answer 3

के रूप में अगर आप दो दृश्य चाहते हैं यह मेरे लिए लग रहा है:

हालांकि, जब उपयोगकर्ता नेविगेशन पट्टी पर 'वित्त' लिंक पर क्लिक करता है, मैं की बाईं तरफ के बैंक खातों को दिखाना चाहते हैं पेज और दाईं ओर लेनदेन के कुछ लेनदेन। दाईं तरफ लेनदेन।

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

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

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

यदि आप सबकुछ वित्तीय दृष्टि में विलय करते हैं, तो चीजों को कम-से-कम रखने के लिए अभी भी संभव है, लेकिन ऐसा करना अधिक कठिन हो जाता है। अतिरिक्त परत अतिरिक्त प्रयास करती है और अवचेतन रूप से आपको सब कुछ एक साथ मर्ज करने के लिए मार्गदर्शन कर सकती है।

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