क्या विभिन्न नियंत्रकों द्वारा फ्रंटेंड और बैकएंड को संभाला जाना चाहिए?

Question

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

सभी रीस्टफुल रेल ट्यूटोरियल में नियंत्रकों के पास show, edit और index व्यू है। यदि कोई अधिकृत उपयोगकर्ता लॉग ऑन है, तो edit व्यू उपलब्ध हो जाता है और index व्यू अतिरिक्त डेटा मैनिपुलेशन नियंत्रण दिखाता है, जैसे डिलीट बटन या edit व्यू का लिंक।

अब मैं एक रेल आवेदन जो इस पैटर्न में वास्तव में गिर जाता है है, लेकिन index दृश्य पुन: प्रयोज्य नहीं है:

1. सामान्य उपयोगकर्ता बहुत सारे चित्र, जटिल लेआउट के साथ एक आकर्षक सूचकांक पृष्ठ देखता है, कोई जावास्क्रिप्ट आवश्यकता ...
2. व्यवस्थापक उपयोगकर्ता सूचकांक एक पूरी तरह से अलग minimalistic डिजाइन, jQuery मेज और अतिरिक्त डेटा के बहुत सारे, ...

अब मैं इस मामले को संभालने के लिए कैसे यकीन नहीं है। मैं निम्नलिखित के बारे में सोच सकते हैं:

1. एकल नियंत्रक, एकल दृश्य: दृश्य दो बड़े ब्लॉकों/एक if कथन का उपयोग partials में विभाजित है।
2. एकल नियंत्रक, दो विचार: index और index_admin।
3. दो अलग अलग नियंत्रकों: BookController और BookAdminController

इन समाधानों में से कोई भी सही लगता है, लेकिन अब के लिए मैं 3 विकल्प का उपयोग करने के लिए इच्छुक हूँ।

ऐसा करने का पसंदीदा तरीका क्या है?

Answer 1

मैंने खुद को इस सवाल से लगभग हर बार पूछा जब मुझे एक नई परियोजना मिलती है। मैं आमतौर पर दो समाधानों में से एक चुनता हूं:

1)। सिंगल कंट्रोलर, सिंगल व्यू

मैं अब तक इस समाधान को आज तक कभी नहीं चुनता जब तक कि परियोजना वास्तव में सरल न हो, और केवल एक या दो प्रकार के उपयोगकर्ता। यदि आपको एकाधिक उपयोगकर्ता प्रकार मिलते हैं तो समाधान # 2 का उपयोग करना बेहतर होता है। हालांकि यह समाधान आकर्षक हो सकता है क्योंकि आपको लगता है कि आप कम कोड लिखकर कुछ समय बचाते हैं, लेकिन अंत में, आपका नियंत्रक और दृश्य जटिलता में बढ़ेगा। उन सभी किनारे के मामलों का उल्लेख नहीं करना जिन पर आपको विचार करना है। यह आमतौर पर बग का मतलब है।

मेरी कंपनी को एक बार एक असफल परियोजना को सहेजना पड़ा, इसमें 3 उपयोगकर्ता प्रकार थे।(व्यवस्थापक, व्यापार, और सदस्य)। उन्होंने समाधान # 1 का उपयोग किया। कोड एक भयानक स्थिति में था, (और यही कारण है कि हमें इस परियोजना को बचाने के लिए कहा गया था) हम मजाक कर रहे थे कि यह एमवीसी नहीं है, यह एमएमएम था। (मॉडल-मॉडल-मॉडल) ऐसा इसलिए है क्योंकि व्यापार तर्क ठीक से निकाला नहीं गया था और मॉडल में डाल दिया गया था, लेकिन नियंत्रकों और विचारों में भी फैल गया था।

2)। एकाधिक नियंत्रक, एकाधिक दृश्य

मैं इन समाधानों का उपयोग इन दिनों अधिक से अधिक करता हूं। मैं आम तौर पर उपयोगकर्ता प्रकार के साथ नियंत्रकों का नामस्थान।

"एप्लिकेशन/नियंत्रक" में

class BookController < ApplicationController 
end 

और "एप्लिकेशन/नियंत्रक/व्यवस्थापक"

class Admin::BookController < Admin::BaseController 
end 

मैं केवल नियमित रूप से उन पर विचार करने के जब मैं BookController में भरने की जरूरत है, और उदाहरण के लिए: जब मैं Admin::BookController

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

Answer 2

उपयोग दो वर्तमान अगर वहाँ दो मॉड्यूल 1] व्यवस्थापकीय 2] उपयोगकर्ता

कहो हैं

class BookUserController < ApplicationController 
    #Here layout is used will be of layouts/application.html.erb 
    #Here all the methods which user can will be present 
end 


class BookAdminController < ApplicationController 
    layout 'admin' #here we set the layout is layouts/admin.html.erb 

end 

अगर केवल एक पृष्ठ आप व्यवस्थापक आप उपयोग कर सकते हैं एकल नियंत्रक और दो तरीकों दिखाना चाहते हैं

class BookUserController < ApplicationController 
    layout 'admin', :only=>['index_admin'] 

    def index_admin 


    end 

    def index 



    end 


end 

या

class BookUserController < ApplicationController 
    def index_admin 

    render :action=>'index_admin', :layout => false 
    end 

    def index 



    end 


end 

Answer 3

मैं ऐसी स्थिति में जो कुछ करता हूं वह काफी हाल ही में बदल गया। वर्तमान दृष्टिकोण निम्नानुसार है:

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

मैं अलग-अलग नियंत्रक में मॉडलों के लिए 'अपनी पहुंच' को अलग करने के लिए भी जाता हूं। मैं आमतौर पर नियंत्रक का नाम भी रखता हूं बस इसे अलग नामस्थान में डाल देता हूं।

यह दृष्टिकोण मानक पुनर्विक्रेता नियंत्रक इनहेरिटेड स्रोतों जैसे कार्यान्वयन का उपयोग करना बहुत आसान बनाता है।

ध्यान दें कि आप विचारों के कई पुन: उपयोग कर सकते हैं अगर एक ही कार्यक्षमता के लिए उपयोग की विभिन्न प्रकार के लिए आवश्यक है।

### lets start with routes 

# this is basically guest access level. you can only list it and see details 
map.resources :books, :only => [:index, :show] 

namespace :my do |my| 
    # this will require at least login. 
    # index and show will be basically same as at the guest level. we can reuse the views 
    my.resources :books 
end 

namespace :admin do |admin| 
    # this will require admin login 
    admin.resources :books 
end 

# now the controllers 

# this might be just enough of a controller code :). the rest goes into model. 
class BooksController < InheritedResources::Base 
    actions :index, :show 
end 

module My 
    class BooksController < InheritedResources::Base 
    before_filter :require_user 

    protected 
    def begin_of_association_chain 
     # this will force resources to be found on current_user.books. 
     # so if you go to /my/books/123 and book 123 is not your book you will get 404 
     current_user 
    end 
    end 
end 

module Admin 
    class BooksController < InheritedResources::Base 
    before_filter :require_admin 

    # this controller is essentially unrestricted. you can get/edit/update any book 
    # and you can have separate view template for index too 
    end 
end 



## Views 
# well, this is the part that I like the least in this approach, but 
# I think the good outweight the bad. 
# I see 2 ways to reuse the views w/o writing lots of ugly customization code for the InheritedResources 
# 1) render 'parent' views inside templates. i.e. like: 
# my/books/index.html.haml: 
!= render :file => "/books/index" 

# or just link the templates on the filesystem level with symlinks. 
# (or if all of them are the same you can link the directory) 

Answer 4

जब मैं एक स्पष्ट रूप से अलग कर प्रशासन क्षेत्र की जरूरत है, मैं एक संसाधन के लिए दो नियंत्रकों के साथ एक समाधान के लिए जाने के लिए करते हैं:

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