Al momento ho un progetto separato per i miei modelli e un progetto separato per un'applicazione API che consuma questo modello. L'intenzione della separazione è quella di evitare qualsiasi dipendenza in uscita dal modello di base per i consumatori come il progetto API, che mi consente di avere una buona struttura a livelli di responsabilità.
In questo caso però, l'API non può utilizzare il modello così com'è, poiché richiede che le classi siano decorate con attributi correlati alla serializzazione dei dati. Poiché questo è esattamente il tipo di dipendenze dal modello che voglio evitare, posso solo vedere la mia unica opzione come DTO intermedio su cui il modello core viene mappato.
Ciò preserva il disaccoppiamento del modello dai suoi consumatori, ma ovviamente introduce alcune ridondanti ridondanze in cui non solo devo creare manualmente tutti i DTO, ma anche mantenerli per abbinarli a un modello core che cambia alla fine. Anche se AutoMapper può occuparsi della mappatura effettiva.
Questo sembra abbastanza sgradevole, ma dal momento che il progetto del modello utilizza un EDMX per definire e generare automaticamente il codice per il modello, sto pensando di cambiare i modelli t4 per generare un'interfaccia per ogni classe e utilizzarla nel consumatore di mettere un contratto sul DTO e persino lasciare che l'IDE li implementa automaticamente dall'interfaccia.
Questo sembra abbastanza ragionevole per il mio, ma mi chiedo se questo possa essere considerato un buon approccio per progetti di livello enterprise, o se mi manchi qualcosa. Immagino che lo strato extra di DTO intermedio possa essere visto come un buon artefatto nel concrezionare una separazione tra il contratto del modello principale e il contratto API. E se è così, forse l'uso dell'interfaccia generata dal modello sarebbe in conflitto con questa separazione, anche se ha alcuni vantaggi netti? Ma in quel caso, forse sarebbe una strategia produttiva utilizzare le interfacce generate automaticamente dove abbiamo un mapping 1-a-1 e creare un set separato di DTO in cui i contratti differiscono effettivamente?
Quindi, per essere chiari, sto cercando un'architettura ben suddivisa e coerente per aumentare le qualità generali del codice statico come la manutenibilità e la coesione. Sopra ho dato un esempio specifico del partizionamento del modello core da parte dei consumatori che cerco di fare mentre razionalizzo su di esso, e la mia domanda è se l'approccio suggerito potrebbe generalmente essere considerato buono o meno. O potrebbe essere troppo specifico per adattarsi a una risposta generalizzata?