भूमिका-आधारित रीस्टफुल संसाधनों के लिए ऐप संरचना

Question

क्या रीस्टफुल संसाधन संसाधनों का उपयोग करते समय उपयोगकर्ता भूमिकाओं को लागू करने के लिए सर्वसम्मति से सर्वोत्तम दृष्टिकोण है?

User has_many Tickets 
Event has_many Tickets 
Ticket belongs_to Person, Event 

और फिर आगे कहते हैं कि मैं उपयोगकर्ता के दो प्रकार के होते हैं:: ग्राहकों और एजेंटों

मैं निम्नलिखित संसाधन हैं कहो। दोनों सिस्टम में लॉग इन करेंगे, लेकिन उनकी भूमिका के आधार पर विभिन्न संसाधनों की पहुंच और कार्यक्षमता के साथ। उदाहरण के लिए:

ग्राहकों तक पहुंच सकते हैं:

• घटना सूचकांक, दिखाने
• टिकट सूचकांक (उपयोगकर्ता द्वारा स्कोप), शो, खरीद/बनाने के लिए, वापसी/हटाने
• व्यक्ति बनाने के लिए, शो, अद्यतन

एजेंटों का उपयोग कर सकते हैं:

• घटना सूचकांक, शो, बनाना, अपडेट,
• टिकट अनुक्रमणिका हटाने शो बेचने/बनाएं, अपडेट, वापसी/हटाने
• व्यक्ति सूचकांक, शो, बनाएं, अपडेट,

हटाना 4 में से कौन सा नीचे सामान्य दृष्टिकोण क्लीनर और अधिक लचीला होगा? भूमिका से

namespace "agent" do 
    resources :events, :tickets, :people 
end 
namespace "customer" do 
    resources :events, :tickets, :people 
end 

अलग नियंत्रकों, उदाहरण के लिए::

AgentController 
    def sell_ticket, etc 

CustomerController 
    def buy_ticket, etc 

अलग-अलग क्रियाएं जहां जरूरत है, उदाहरण के साथ

साझा नियंत्रकों:

भूमिका फोल्डर और नामस्थान में संसाधनों, जैसे भीतर

अलग नियंत्रकों

TicketController 
    before_filter :customer_access, :only => :buy 
    before_filter :agent_access, :except => :buy 

    def buy #accessed by customer to create ticket 

    def sell #accessed by agent to create ticket 

सशर्त बयान के साथ साझा क्रियाएं, उदाहरण:

TicketController 
    def create 
    if @role == :customer 
     #buy ticket 
    elsif @role == :customer 
     #sell ticket 
    end 
    end 

Answer 1

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

@ticket = Ticket.new(params[:ticket]) 

if @ticket.save 
    redirect_to @ticket 
else 
    render :action => "new" 
end 

लेकिन अपने विचारों बस अनुकूलित किया जा सकता:

<% if customer? %> 
    Customer area. 
<% else %> 
    Agent area. 
<% end %> 

Answer 2

मैं पिछले दो प्रस्तावित कार्यान्वयन के संयोजन का उपयोग सुझाव है। वे विश्वसनीय प्रतिनिधित्व का पालन करते हैं, उन्होंने उचित स्तर (नियंत्रकों) पर प्राधिकरण रखा है, और यह एक स्केलेबल कार्यान्वयन है।

REST, अनिवार्य रूप से, लगभग accessing nouns with verbs है। तो आप एजेंटों और ग्राहकों को टिकट, उपयोगकर्ता, और घटनाओं (संज्ञा) के संबंध में क्रियाएं (क्रियाएं) करना चाहते हैं। इन संज्ञाओं का सटीक रूप से प्रतिनिधित्व करने के लिए आपके पास प्रत्येक के लिए नियंत्रक होना चाहिए। ग्राहक तब यूआरएल, http://example.com/events/22 द्वारा देखे जा रहे संसाधन की पहचान कर सकते हैं।यहाँ से आप की तरह कुछ करने से, विभिन्न संसाधनों के लिए संदर्भ का प्रतिनिधित्व करने यानी http://example.com/events/22/tickets रेल 'रूटिंग का उपयोग कर सकते हैं:

resource :events do 
    resource :tickets 
end 

एक RESTful वास्तुकला का पालन करके, आप end to end principle में खरीद रहे हैं। वस्तुओं का प्रतिनिधित्व करने के लिए प्रतिमान केवल इसके लिए ज़िम्मेदार होना चाहिए। इसे प्रमाणित करने की कोशिश नहीं करनी चाहिए। यह उसका काम नहीं है। नियंत्रकों में प्रमाणीकरण होना चाहिए। मैं CanCan या Declarative Authorization जैसे रत्नों की तलाश करने की अत्यधिक अनुशंसा करता हूं जो यह सब आपके लिए सेट करते हैं।

अंत में, यह मॉडल स्केलेबल है। अपने संसाधनों के प्रतिनिधित्व से प्राधिकरण को अलग रखते हुए आपको केवल इसका उपयोग करना होगा यदि आपको इसकी आवश्यकता है। यह आपके आवेदन को प्रकाश, लचीला और सरल रखता है।

Answer 3

हालांकि वे दोनों टिकट बनाने के साथ सौदा करते हैं, ग्राहक/टिकट खरीद बनाम ग्राहक/टिकट खरीददारी मेरे लिए काफी अलग दिखती है कि उन्हें अलग किया जाना चाहिए। अंततः वे आगे बढ़ सकते हैं क्योंकि शुरुआत से ही उनका उपयोग अलग-अलग किया जा रहा है। ,

module TicketsControllersCommom 
    # common helper methods 
end 

class TicketsController < ApplicationController 
    include TicketsControllersCommom 
    # actions 
end 

class AgentTicketsController < ApplicationController 
    include TicketsControllersCommom 
    # actions 
end 

मैं व्यवस्थापक अनुभाग का एक प्रकार के रूप में एजेंट भागों का इलाज हो सकता है ग्राहक भागों होने के साथ:

यह संभव या तो मॉड्यूल के साथ या एक आम माता-पिता नियंत्रक से इनहेरिट द्वारा नियंत्रक कार्यक्षमता को साझा किया है करने के लिए है डिफ़ॉल्ट:

012:

/events/xx/tickets # collection 
/events/xx/tickets/xx # member 
# etc. 
/events/xx/agent/tickets # collection 
/events/xx/agent/tickets/xx # member 
# etc. 

या, यदि आप व्यवस्थापक प्रकार सामान का एक बहुत है, की तरह है, तो एजेंट के रूप में अच्छी तरह से घटनाओं का प्रबंधन, आप एक पूरे अनुभाग नाम स्थान कर सकते हैं