Contesto
Ho una linea di applicazione aziendale "MyApp" in C # usando EF. I livelli sono separati come
- MyResusableLib.DataAccess // Class Lib: utilità basate su EF, metodi di estensione,
- MyApp.DataAccess // Class Lib: EF edmx, classi del modello generate
- MyApp.DataServices // Class Lib: dipende dalle classi Model in MyApp.DataAccess (Nota: i servizi sono solo POCO e non hanno nulla a che fare con un'API Web. Ad esempio, PaymentService.Storno (...))
- ecc.
Ho scoperto che alcune tabelle universali (almeno cinque) saranno comuni in tutta la mia futura linea di applicazioni aziendali. Quindi i servizi di alto livello implementati non devono essere copiati su MyApp1.DataServices su MyApp2.DataServices, invece dovrebbe essere collocato un lib di classe MyReusableLib.DataServices appena creato
Problema:
Il contesto EF e le classi del modello saranno in futuro creati MyAppX.DataAccess. Tuttavia MyReusableLib.DataServices dipende da tali classi del modello.
Domanda:
Qual è la migliore architettura per superare il problema e usufruire di MyReusableLib.DataServices con i suoi servizi di alto livello sullo storage persistente?
Soluzione proposta:
Mi viene in mente solo una soluzione, ma non ne sono sicuro. Soprattutto non so se ci sono degli svantaggi, e inoltre non so se c'è una pratica migliore. Uno di sicuro: vorrei finire con una soluzione ASCIUTTA.
- Avrò due edmx e contesti EF (che puntano allo stesso database quando le stringhe di connessione saranno configurate nella mia futura MyAppX.)
- Il primo contesto EF edmx verrà definito in MyReusableLib.DataServices e conterrà le cinque tabelle / entrate riutilizzabili. I servizi implementati (anche nell'assembly) possono utilizzare tali classi di modelli.
- Il secondo contesto EF edmx verrà definito nella mia futura MyAppX. Conterrà tutte le tabelle specifiche e non conterrà le tabelle riutilizzabili.
- Il database fisico di MyAppX conterrà sia le tabelle riutilizzabili sia le tabelle specifiche.