Avere un livello di accesso ai dati generico per interfacciare un database è un approccio standard e ci sono diversi strumenti ORM che consentono effettivamente di generare automaticamente le classi del modello da un database esistente.
Dato che hai menzionato il framework di entità, questo è chiamato "database first" in quel contesto. Il modo ingenuo di applicare gli strumenti di Microsoft per generare classi di modelli porterebbe a un livello di accesso ai dati con (circa) una classe per tabella, quindi uno che "rispecchia il DB" . Tuttavia, da quello che hai scritto è chiaro che avrai bisogno solo di un sottoinsieme di queste classi modello. Pertanto, per ottenere il codice generato per questo sottoinsieme, consulta questo post SO precedente .
Se ti occorrono solo in modalità di sola lettura , potresti semplicemente non utilizzare alcuna operazione di inserimento, aggiornamento o eliminazione o nasconderli dal contesto DB, come mostrato qui . Quando le tue app non hanno bisogno di accesso in scrittura, potrebbero connettersi al DB utilizzando un utente speciale che ha solo i diritti di accesso richiesti. AsNoTracking è AFAIK solo un'opzione di ottimizzazione delle prestazioni per l'accesso di sola lettura, vedi questo post SO .
Quindi la domanda rimane se uno dovrebbe mettere tutte quelle classi generate in una libreria condivisa, o meglio generare diverse librerie di accesso ai dati, una per ogni app?
Questo dipende in realtà dalle app, da quanto sono indipendenti, da come devono essere mantenute indipendenti, quanta manutenzione è effettivamente necessaria e se c'è un sacco di codice scritto manualmente sulle classi di modelli generate che possono essere condiviso tra le diverse app. Se non esiste un codice di questo tipo, probabilmente non vi farà male se ognuna delle app avrà il proprio livello di accesso ai dati generato individualmente, ognuna delle quali includerà solo le classi di modello richieste. Anche se c'è qualche sovrapposizione nelle tabelle e alcune classi verranno generate 10 volte, non c'è alcun problema di manutenzione reale. Se le tabelle sottostanti cambiano, si può semplicemente rigenerare nuovamente quelle classi. Ovviamente, per questo dovresti inserire i comandi di generazione per ogni livello dell'applicazione in uno script da riga di comando che diventa parte della tua base di codice.
Se invece dovessi scrivere un sacco di codice duplicato sopra le classi generate, ad esempio alcuni repository o logiche di business comuni, che possono essere condivisi tra quelle app, comincerà a pagare per metterle codice in una libreria condivisa. Questo è un enorme miglioramento per la manutenzione e la successiva evoluzione dei programmi, tuttavia, ha un costo:
-
ogni volta che la tua libreria cambia per qualche motivo, dovrai ricompilare tutte le app dipendenti per assicurarti di non apportare alcune modifiche retroattive (o devi adattare tutte le app dipendenti contemporaneamente quelle modifiche)
-
devi anche prendere una decisione se vuoi che tutte le tue app siano trattate come "un sistema" (quindi dai loro un numero di versione comune e ridistribuiscile tutte in una volta quando qualcosa cambia), oppure se vuoi ancora distribuirli separatamente, il che porterà a una situazione in cui hai diverse versioni della tua lib condivisa allo stesso tempo in produzione.
In generale questo è un trade-off, vedi questo il vecchio post SE.SE su quando avere una "libreria di base" è un'idea buona o cattiva. La risposta più in alto porta a un altro link che potrebbe interessarti, un buona discussione di "ridondanze e dipendenze" nella creazione di librerie.