Come utilizzare le stesse entità in più progetti con il framework entità?

Naviga le tue risposte
-2

Devo creare due diversi progetti con Entity Framework:

  • Servizi API Web
  • UI e Business Logic (MVC).

Entrambi i progetti devono lavorare con le stesse entità POCO. Vedo due alternative e vorrei conoscere i pro e contro di ciascuno, e se uno dei due è raccomandato come migliore opzione:

  1. Crea una libreria di classi diversa per il modello di entità completo e prendi il suo riferimento in entrambi i progetti?
  2. Creare la libreria di classi solo per le entità POCO, prendere il suo riferimento in entrambi i progetti e utilizzare il primo approccio al codice nel progetto di servizi (creando la classe di contesto) per l'accesso al database?

Inoltre vorrei sapere come strutturare meglio i miei progetti quando ho tre server diversi, uno per i servizi Web, uno per l'interfaccia utente e uno per il database. D'altra parte, se devo seguire il primo approccio al database, come faccio a gestire questa situazione?

    
posta MNP 30.08.2017 - 18:28
fonte

1 risposta

0

Non sono sicuro che la tua architettura di progetto prevista sia ottimale.

L'API web dovrebbe esporre servizi che forniscono accesso agli oggetti del dominio insieme alla logica aziendale. Questo livello di servizio userebbe la struttura dell'entità per la gestione dell'accesso al database.

Il livello di presentazione deve offrire l'interfaccia utente, ma non deve confondersi con la logica aziendale né accedere direttamente alle entità. Dovrebbe accedere alle entità e alla logica aziendale solo tramite i servizi web. Un muto trasferimento dati oggetto potrebbe essere utilizzato per trasferire i dati tra il livello di servizio e l'interfaccia utente.

Questa architettura eviterebbe l'accoppiamento stretto che si avrebbe utilizzando una libreria condivisa (qualunque sia l'alternativa che si ha), in cui ogni modifica potrebbe avere un impatto su tutti gli altri componenti. Garantire inoltre che il livello dell'interfaccia utente abbia solo l'interfaccia utente e non gestisca in modo nascosto alcune logiche di business che sono state dimenticate nel livello di servizio.

Infine questa architettura alternativa ti permetterebbe la massima flessibilità per la distribuzione dei livelli: potresti avere tutto su un server, o avere il livello di presentazione (UI ma usando MVP piuttosto che MVC) su un server, la logica del dominio con il database su un altro, o addirittura hanno ogni livello sul proprio server.

P.S: a mio parere, la questione POCO diventa irrilevante con l'architettura alternativa

    
risposta data 31.08.2017 - 08:56
fonte

Leggi altre domande sui tag

Possiamo costruire app per dispositivi mobili utilizzando JavaScript (NON Java)? [chiuso] Inserimento di informazioni di background in termini di DDD