Polymorphism contro autorizzazione

Question

Polymorphism contro autorizzazione

#1 da (1 voti)

0

Ho qualcosa che mi infastidisce nella comprensione del polimorfismo (vs ruolo):
Nota: sto usando le rotaie (ma è una domanda generale)

Ho 4 modelli :

utente
Pro
Clienti
Società

Esiste una associazione polimorfica (profilabile) tra Pro / Cliente e Utente [perché Pro ha molti più campi per il processo di registrazione rispetto al Cliente].

L'utente è usato per la sessione (sto usando la devise gem)

In pratica si usa qualcosa di molto simile a questo scritto:

link

Associazione aziendale

Ora desidero creare la mia associazione con la Società.
Ormai solo Pro ha una sola azienda (ma credo che potrebbe essere un altro profileable_type che può anche avere un'azienda).
Il cliente non ha una società.

In tal caso, quale associazione è preferibile:

Approccio 1

L'utente ha_una società
La società appartiene_per utente
e gestire l'autorizzazione (con una gemma come cancan) per consentire la creazione dell'azienda solo per Pro (con il mio campo profileable_type nella tabella utente)

o

Approccio 2

Pro ha_una società
La società appartiene al professionista
Quindi in tal caso non ho più bisogno di alcuna gestione delle autorizzazioni (l'Utente (e per estensione Cliente) non può creare la società per impostazione predefinita)

Alla ricerca di pro / contro dei 2 approcci. Sono piuttosto sicuro che il primo è la soluzione migliore dato che ho un user_id nella mia tabella aziendale che sarebbe più generico ed espandibile rispetto a un pro_id. Sarei lieto di esserne sicuro. Grazie!

polymorphism authorization role

posta benoitr 19.07.2013 - 11:05

fonte

1 risposta

Leggi altre domande sui tag polymorphism authorization role

Come creare script per la creazione e la configurazione di un ambiente di sviluppo Windows 7 portatile (basato su VM?)? [chiuso] Che cos'è Script Binding e come è fatto?

score 1 · Accepted Answer

(Venendo da C # / Java, si spera che tu possa tradurre di nuovo in rotaie :) L'approccio 1 è la strada da percorrere. User deve essere in grado di prendere un'azienda, restituire un'azienda e lasciare che il codice che utilizza la classe sappia se il primo metodo memorizza qualcosa e il secondo restituisce qualcosa tranne che null. Customer non farebbe nulla nel primo metodo, restituirà null dal secondo e l'ultimo (terzo) metodo restituirà false. Pro potrebbe effettivamente salvare e restituire un'azienda e restituire true per il terzo metodo.

Ciò significa che puoi passare e lavorare con User e dimenticare approssimativamente Pro e Customer per la maggior parte del tempo. E puoi aggiungere altre sottoclassi (modelli?), Alcune delle quali hanno società e altre no, e tutto il tuo codice che usa User funzionerà ancora senza modifiche. Aggiungi altri concetti oltre alle aziende e i vantaggi si moltiplicano.

Espansione:

User non dovrebbe in realtà avere la funzionalità per prendere un'azienda, deve solo apparire come può, quindi il codice non deve sempre preoccuparsi se un User è o meno a Pro . A un certo punto potrebbe essere chiesto a User se può gestire un'azienda, e un Pro dirà "sì" e un Customer "no". In C # / Java (e spero che questo si traduca in qualche modo su binari) una chiamata a "SetCompany" probabilmente genererebbe un'eccezione. (Un ritorno nullo da "GetCompany" potrebbe essere migliore di un'eccezione.)

Se viene creata un'altra classe, A, che può avere una società, l'estensione di Pro è una buona idea. (O avendo Pro e A estendi una terza classe astratta (o non) che ha il codice per gestire un'azienda.) Ma questo è visibile solo all'interno della nuova classe. Tutto il codice scritto per gestire User oggetti non ha bisogno di sapere su di esso, che è l'intero punto. Tutto quello che stai facendo è mettere il codice per gestire le aziende in un unico posto (ASCIUTTO). Nessuno ha mai bisogno di chiedere se hanno un'istanza di Pro . Chiedono solo un oggetto User (estensione sconosciuta) se può gestire un'azienda.

E potrebbe un giorno avere bisogno di un'estensione User che gestisca le aziende, ma in un modo così diverso da non voler usare il codice Pro . Con User "gestione" delle aziende, tutto questo può essere fatto in modo trasparente.