Come ricreare questo controllo accessi / gruppo / qualsiasi metodologia in OO / MVC

Naviga le tue risposte
3

Sto cercando di riscrivere un'applicazione che è per lo più procedurale rispetto a un approccio MVC / OO al fine di insegnarmi una comprensione più profonda di entrambi.

BUT, sto riscontrando alcuni problemi concettuali con il gruppo attuale / controllo di accesso che viene utilizzato.

Abbiamo Gruppi (Aziende) che hanno utenti basati su ruoli (Manager, venditori, clienti). Possono avere clienti assegnati a un venditore, oppure no. Il manager vede tutto, l'addetto alle vendite solo i clienti a lui assegnati. 

Business
  |
  ---Manager
       |
       ---Salespersons
            |
            ---Customers
  |
  ---Customers

La struttura della tabella per questo attualmente è qualcosa del tipo: 

users (userID [demographic info])
business (businessID, userID, et al [demographic info])
salespeople (salesID, businessID, userID [just foreign keys])
customers (customerID, businessID, userID, et al [demographic info])
salesAssignments (salesID, customerID [just foreign keys])

Il Manager può influenzare tutti all'interno di quel gruppo di aziende (ognuno ha un businessID che li collega a quell'attività e nessun altro). I clienti possono accedere e apportare modifiche minori ai loro profili o interagire tramite messaggistica al proprio venditore o al responsabile delle attività commerciali.

Aggiunto Spice al mix: (commenta uno di questi se si applicano alle tue intuizioni alla domanda precedente) Esiste un modo migliore per avere un accesso e un controllo degli utenti simili? Voglio ricostruire il sito con un'API che può essere utilizzata sia dall'app Web sia dalle app mobili.

Modifica Il mio principale blocco concettuale al momento riguarda come ricreare questa struttura in un oggetto utente per la parte OO dell'applicazione. Ora tutto è accessibile tramite variabili di sessione, o interrogato dal DB tramite funzioni procedurali. Ancora una volta la mia comprensione di OO è limitata, e questo è un tentativo di capirlo.

    
posta jayhoakan 11.12.2013 - 23:31
fonte

3 risposte

1

Crea una classe utente, quindi una classe che ne eredita per ogni tipo di utente. Aggiungi una raccolta di tipi appropriati a ciascuna di queste classi per le relazioni secondarie, ad es. 

class User {}

class Manager : User
{
    Collection<SalesPerson> SalesPeople { get; set; }
}

class SalesPerson : User {}

Ora, quando hai un manager, puoi navigare nelle persone di vendita correlate (supponendo che l'elenco sia compilato correttamente)

    
risposta data 11.01.2014 - 04:52
fonte
0

Concettualmente, il modo in cui ottieni questo nel tuo repository è di limitare i tuoi accessi al database aggiungendo una clausola WHERE al tuo SQL, con l'effetto di: 

WHERE <User is manager> OR UserID = <currently logged in employee id>
    
risposta data 11.12.2013 - 23:39
fonte
0

Potresti implementare le autorizzazioni usando il tipo di oggetto tipo link

Quindi ognuno dei tuoi utenti avrebbe una proprietà type che definisce il loro tipo in 1 o 2 modi.

  1. proprietà di oggetti di tipo diverso es. typeName
  2. tipo gerarchia di ereditarietà degli oggetti

1 ha il vantaggio che tutti gli oggetti type sono della stessa classe e quindi possono sempre essere trattati in modo identico ed è abbastanza semplice interrogare il tipo di un oggetto.

2 ha il vantaggio di specificare proprietà di tipo differenti che si applicano solo a quel tipo (ed è sottotipi), ad es. il tipo Manager può avere la proprietà groupSalesTarget che potrebbe non avere senso per un cliente

Uno dei grandi vantaggi di questo modello in generale è la facilità di aggiornamento e downgrade delle autorizzazioni dei singoli utenti.

    
risposta data 06.01.2015 - 12:20
fonte

Leggi altre domande sui tag

Flusso di lavoro Git - probabilmente rami a lungo funzionamento per la versione futura HMVC e connessioni di database