Ecco una regola empirica (ma non seguirla ciecamente! Comprendi perché devi usarla!) per la direzione che le tue dipendenze devono seguire
Always depend in the direction of abstraction and stability
Ciò significa che le dipendenze da cui dipendono tutti devono essere le dipendenze che cambiano meno. Tutti dipendono da loro, quindi sono costosi da cambiare. Quindi progettare quelle dipendenze per avere poco o nessun motivo per cambiare!
E un modo per farlo è quello di rendere quelle dipendenze principalmente dall'interfaccia non implementata e una stupida struttura dati che serve solo a trasferire informazioni tra gli oggetti. Quindi, un modulo più supponente, come l'interfaccia utente e il livello di accesso ai dati e varie parti della logica aziendale, implementa tali interfacce con oggetti di grandi dimensioni che svolgono effettivamente il lavoro. Questo è chiamato il principio di inversione delle dipendenze .
Ora, la direzione che la freccia dei livelli deve assumere dipende da chi sta parlando: "L'interfaccia utente deve dipendere dalla logica aziendale che dipende dall'accesso ai dati! No! La logica aziendale deve essere al centro e tutti dipendono da questo! " Molte opinioni e religioni, ma è tutto inutile alla fine. Che importa è l'astrazione. Se le tue dipendenze sono attraverso elementi astratti, allora ce l'hai. Il resto è puro dibattito intellettuale inutile.
Quindi, per rispondere alla tua domanda, ti chiederò un altro "Quali sono le ragioni per cui la tua cosiddetta entità deve cambiare?" Hai la risposta nella tua stessa domanda:
As POCO entities used in a dbContext are in fact a definition of the database
Se la tua entità è una definizione del database, significa che cambierà ogni volta che il database cambia . E se devono conformarsi a un dbContext, ciò significa che hanno un strong accoppiamento con Entity Framework. Se Microsoft decide di cambiare il modo in cui EF lavora, le tue entità dovranno cambiare. Le tue entità non saranno le simpatiche astrazioni di cui hai bisogno per ridurre al minimo l'accoppiamento.
Quindi sì, in tal caso, se vuoi considerarli un modello del database, dovresti nasconderli in un livello di persistenza e assicurarti che nessuno li veda mai che non sanno anche del database .
In sintesi, se vuoi un'applicazione che è ben disaccoppiata e strongmente coesiva, no, non dovrebbero essere dipese da tutti, perché se lo fai, ognuno dipenderà in modo transitorio dalla struttura del database. Quindi ogni volta la modifica del database, l'intera applicazione dovrà cambiare e sarà un problema. Il modo in cui la gente di solito fa fronte è quello di non modificare il database e di introdurre molta rigidità nella memorizzazione dei dati. A un certo punto o l'altro il database sarà necessario cambiare, e a quel punto dovrai pagare un pesante prezzo del debito tecnico.
Quanto sopra era neutrale come posso farcela, il resto sarà più supponente. Sentiti libero di ignorarlo se non si adatta alle tue opinioni.
Le tue entità dovrebbero essere la base della tua domanda e tutti dovrebbero dipendere da loro. Non dovrebbero, mai , essere un'implementazione del database. Il lavoro sull'entità della struttura è di piegare intorno alla tua entità, e se non può farlo, allora non è la struttura che fa per te: buttala via il prima possibile. Non dovrebbe avere alcun potere sulla tua entità. TU decidi come sono strutturate le tue entità. Non comprare la promessa di magia che i conceptor demo ti stanno mostrando. A un certo punto o l'altro dovrai fare qualcosa di inaspettato, tutta la magia scomparirà e dovrai lasciare il tuo bel mondo onirico e scrivere il codice che avevi davvero bisogno dall'inizio.
Cerca di rendere le tue entità un'astrazione del tuo modello di dominio (che è molto meno probabile che cambi), ea quel punto, tutti saranno in grado di dipendere da loro, e il tuo database sarà libero di essere implementato come vuoi tu. All'inizio avrai meno magia e codifichi di più, ma nel tiro lungo vincerai su tutti i conti.