Is it a good practice to always decouple the entity classes from the
presentation layer by implementing a domain object (or "view" object)?
L'accoppiamento lento e l'alta coesione sono solitamente due principi fondamentali che vale la pena implementare. Tuttavia, dobbiamo tenere presente che l'implementazione di questo tipo di best practice ha un costo. Un notevole aumento della complessità, che viene spesso tradotto in più componenti da implementare e mantenere. Un codice sorgente più difficile da immaginare e da comprendere a prima vista.
Dovrai pesare se i vantaggi di queste pratiche compensano i costi di implementazione e manutenzione. Ad esempio, se è improbabile che il codice sorgente cambi o se cambia molto di tanto in tanto, potresti non apprezzarne i vantaggi in qualsiasi momento. Se il tuo codice è già testabile, probabilmente entrambi.
Which approach would you take for that?
Vorrei dare una possibilità ad alcuni modelli di design ben noti. Come per esempio MVC , MVP e MVVM . Onion Architectecture anche in base alle dimensioni dell'applicazione.
I was thinking about first rules and best practices and conventions
at the beginning of a project. I think it makes sense, don't use the
entities of Entity Framework in the view models.Instead of the EF
classes, I can use a "view" object. I want to define a rule that in
presentation layer is better don't use EF classes
Law of Demeter può aiutarti con le linee guida delle convenzioni del codice. Viene spesso introdotto come principio per progettare l'interoperabilità dei componenti a bassi livelli di astrazione. Ma funziona per livelli più alti di astrazione.
Ad esempio:
-
Livello di persistenza . Le entità persistenti vivono in e solo in questo livello. Nessun business di dominio è implementato qui. I componenti a questo livello sono responsabili del recupero e della memorizzazione dei dati. Il modello persistente può essere semplice come mappatori di righe, mappe o matrici. Il modello dei dati di persistenza è accessibile solo dai livelli superiori tramite le astrazioni appropriate (DAO, Gestori entità, ecc.)
-
* Livello dominio *. Il modello di dominio e tutte le regole aziendali vivono qui. La persistenza è delegata al livello di persistenza . Il modello di dominio non espone mai le entità di persistenza ai livelli superiori. I livelli superiori hanno accesso al modello di dominio tramite le astrazioni appropriate (repository e servizi di dominio). Per semplicità, non è necessario alcun DTO. Il dominio è agnostico ai bisogni degli strati esterni. DTO e mappatori dovrebbero trovarsi in quegli strati che ne hanno bisogno. Il modello di dominio non corrisponde necessariamente a 1 a 1 il modello di persistenza. Hanno preoccupazioni diverse, quindi sono cose diverse.
-
Livello di controllo . I controllori vivono qui e rappresentano il ponte tra l'interfaccia utente e il modello di dominio. L'accesso al modello di dominio avviene attraverso le astrazioni appropriate (repository e servizi, ecc.). Per impedire l'accoppiamento tra l'interfaccia utente e il modello di dominio, i controllori eseguono il mapping delle entità di dominio su un altro modello. DTOs. I DTO non sono Visualizza modelli . Visualizza i modelli appartengono all'interfaccia utente.
La legge di Postel può aiutarti anche a prendere decisioni in merito all'interoperabilità tra livelli e livelli.
Il mio consiglio è, non provare i disaccoppiamenti pesanti. Ci sarà sempre un piccolo accoppiamento da qualche parte. Sii flessibile.
Seguire questi e altri principi (convenzioni, buone pratiche, ecc.) dovrebbe servire a uno scopo reale. Applicale mentre continuano a fornire valore all'applicazione.
Ricorda che le soluzioni non dovrebbero mai essere più complesse dei problemi che risolvono (idealmente). KISS e YAGNI dovrebbero aiutarti a ricordare questa premessa.