Abstracton layer per controllare l'accesso ai servizi all'entità db denormalizzata

Question

Abstracton layer per controllare l'accesso ai servizi all'entità db denormalizzata

#1 da (1 voti)
#2 da (1 voti)
#3 da (1 voti)

3

Il nostro db è ottimizzato per il numero minimo di join (parzialmente denormalizzato). Per esempio. la nostra entità User contiene i dati dell'account (nickname, ID facebook, ecc.), le statistiche numeriche dell'utente (totale partite giocate, vincite totali, ecc.), le informazioni utente relative alla gilda (ID della gilda, tipo di iscrizione, ecc.) e così via - tutto in la stessa tabella.

Usiamo ORM - NHibernate. La tabella user è mappata (con tutti i campi) a User class.

Ora sto rifattorizzando una classe modello AccountManagementService che offre la possibilità di eseguire alcune azioni su un User racchiuso. Il modello ha le due dipendenze: NHibernate e l'entità User . La logica del modello è strettamente legata ai metodi ORM (esegue selezioni, aggiorna).

Penso che sia sbagliato che la modella conosca così tanti campi che non userà. Non ha bisogno di User.GuildId , statistiche, ecc. Ma dal momento che il modello dovrebbe già usare ORM è logico che dovrebbe conoscere le classi di entità.

Sono anche preoccupato che alcune operazioni con User debbano essere eseguite solo tramite servizi speciali, ma altri servizi possono teoricamente accedere e modificare qualsiasi campo di User . Per esempio. AccountManagementService non dovrebbe cambiare User.Money direttamente ma usare UserMoneyService . Ma da un punto di vista del compilatore tale cambiamento è perfettamente valido.

Devo introdurre altri livelli di astrazione tra servizi ed entità per controllare un accesso e come posso farlo? Riesci a vedere altre possibilità per migliorare la situazione?

c# database architecture layers nhibernate

posta Vlad 20.06.2015 - 22:23

fonte

3 risposte

Leggi altre domande sui tag c# database architecture layers nhibernate

Classe diventando Dio Oggetto quale modello usare Creazione di un'interfaccia solo per disaccoppiare da librerie di terze parti

score 1 · Answer 1

Probabilmente vorrai un po 'di strato (potrebbe essere un modello di facciata) che esporrà solo i campi necessari. Sembra che in questo momento stai esponendo i tuoi modelli ORM a tutti i livelli e creando un codice spaghetti / non protetto:)

Inizia definendo le responsabilità chiare di ogni livello e esponendo solo i dati del modello necessari per i livelli precedenti.

Se è necessario un livello di traduzione intermedio, così sia.

score 1 · Answer 2

Nella visualizzazione ingrandita, sembra un modello di dominio Anemico (Martin Fowler - link )

Questi oggetti di accesso ai dati sono un'associazione diretta al database e non riflettono la logica aziendale.

La strada da percorrere sarebbe probabilmente un modello CQRS ( link -query_separation), ma probabilmente ti costringerebbe a rifare il sistema completo.

Probabilmente dovresti leggere: Patterns of enterprise application architecture. Penso che troverai una buona risorsa. Il suo argomento principale sono i modelli di mappatura del database.

Qui non c'è davvero alcuna via d'uscita da uno strato intermedio. Vorrei fare una lezione per rappresentare ciascun dominio aziendale e quindi associarlo ai DAO. Non ci sarà scampo da spagetti

score 1 · Answer 3

Il tuo problema sembra causato dall'inosservanza del principio di segregazione dell'interfaccia. Fortunatamente, c'è una soluzione abbastanza semplice: prendi gli oggetti di entità e crea un'interfaccia in ciascuno per ogni tipo di client, contenente solo i metodi che hanno senso per quel cliente. Quindi, per ogni cliente, crea un wrapper per il tuo ORM che funziona utilizzando le interfacce appropriate per quel client piuttosto che le classi di entità concrete. Infine, per combattere il problema del modello di dominio anemico sopra identificato, è possibile avviare il refactoring spostando i metodi che operano sulle interfacce di entità dai servizi client all'entità stessa.