Progettazione di un repository comune

2

Cosa ho:

Sto sviluppando un livello di Active Directory che verrà utilizzato da una vasta applicazione con diversi moduli con diverse soluzioni e progetti ...

Sono abbastanza nuovo nello sviluppo di soluzioni su larga scala.

Poiché i requisiti attuali riguardano principalmente gli oggetti Utente e Gruppo in Active Directory, la mia soluzione attuale è simile a questa,

  • Estensioni
    • UserPrincipalExtension (che eredita da System.DirectoryServices.AccountManagement.UserPrincipal per aggiungere attributi personalizzati e sovrascrivere i metodi FindByIdentity )
    • GroupPrincipalExtension (come sopra ma con GroupPrincipal ...)
  • Modelli (i modelli hanno metodi di sovrascrittura, ad esempio toString , costruttori ecc.)
    • ADUser
    • gruppo di annunci
    • utente
    • SomeUserObject
    • e così via ...
  • Repositories
    • ADUserRepo (CRUD per utente, + isUserInGroup tipi di metodi)
    • ADGroupRepo (CRUD per gruppo, + GetUsersInGroup tipi di metodi)
  • Generale
    • Utili (Ottieni contesto, ecc.)

Quello che voglio O la confusione è:

Poiché alcuni metodi sono in qualche modo comuni tra i repository utente e di gruppo, sarebbe utile spostare tutti i metodi fuori da UserRepo e GroupRepo in una singola classe DirectoryRepo ed eliminare questi repository?

Al momento questo sta creando confusione per me che lo sta sviluppando, ma potrebbe confondere o forzare un consumatore di questo codice ad aggiungere metodi duplicati.

Come posso superare questo problema?

Ho chiamato questi repository ma questi sono solo metodi statici che accedono a AD, scusa se ciò creava confusione.

Ecco alcune delle mie precedenti domande su SO, se vuoi vedere alcuni dei relativi codici

link

link

    
posta Mathematics 22.09.2015 - 15:25
fonte

1 risposta

2

La chiave per rispondere a questa domanda è l'uso dei repository. Ci sono casi in cui verrebbe utilizzato solo l'Utente o solo il repository di Gruppo? Nella maggior parte dei casi è più probabile che acceda contemporaneamente a Utente e Gruppi? Una volta che puoi rispondere a queste domande, sarai in grado di determinare quale sia "Giusto" per la progettazione dell'applicazione.

In una applicazione che stavo lavorando i repository erano molto frammentati (1 per tabella di database) e usarli era molto complicato. Dopo alcuni refactoring eravamo in meno repository ma con schemi di accesso più logici. IE: un utente ha sempre avuto bisogno dei gruppi di cui faceva parte e ai gruppi non è mai stato effettuato l'accesso tranne durante l'accesso agli utenti, quindi abbiamo combinato i 2 insieme mentre sono andati insieme.

Dato che questa è una nuova applicazione, guarderei a tenerle separate poiché sarà più facile combinarle (IMO) piuttosto che romperle in seguito. Se dopo alcuni sviluppi si scopre che averli separati ti fa sempre istanziare entrambi i repository, li combinerei a quel punto. Nessun punto che istanzia 2 oggetti nel 90% del tuo codice solo per istanziare 1 oggetto nel 10%.

    
risposta data 22.09.2015 - 15:50
fonte

Leggi altre domande sui tag