Database Yukky ... beh, dato che esiste quindi la prima cosa che devi fare è consentire l'accesso al DB solo tramite sprocs, incapsulare efficacemente il DB nella propria API. Una volta fatto ciò, sarà eventualmente possibile sostituirlo / riprogettarlo senza che nessun client lo sappia.
Sembra che tu abbia già fatto questo, così buono finora.
Ora, l'accesso a quell'API può essere fatto in vari modi, e usare EF per farlo è un buon modo RAD per farlo, anche se SQLClient sarà più veloce - non fa troppa differenza in tutto.
Mappare i risultati di uno sproc a un ComplexType è esattamente ciò per cui è progettato un ComplexType (non provare a usarlo come se era una visualizzazione EF di un DB ). È un tipo di risultato temporaneo che non esegue il mapping alla tabella sottostante, ovvero un tipo generato dinamicamente che contiene solo i risultati dello sproc e non ha alcuna relazione con la struttura DB effettiva.
Tuttavia, il problema si presenta quando provi a scriverli di nuovo nel DB - devi dire a EF che i dati nel tipo sono mappati su una tabella DB (o non sapranno cosa fare con esso), e stiamo cercando di rimuovere l'intero schema DB dal codice del servizio, accedendo al DB solo attraverso i suoi sproc. Se si dispone di sprocs per scrivere, non vi è alcun motivo per cui non è possibile semplicemente deselezionare i singoli elementi del tipo e passarli al relativo sproc nel servizio WCF. In questo caso, è sufficiente semplificare il codice del servizio al codice cliente poiché EF crea la classe per te. Ovviamente, se hai già queste classi per lo sproc, non ti aiuterà molto.
Quindi penso che sia sicuro di dire che ha ragione, è un meccanismo di convenienza semplice e utile che dovrebbe funzionare bene per te - supponendo che tu non stia cercando di sovvertire i fili, o di avere un meccanismo simile in atto. Potresti trovare dei problemi nell'ottenere la definizione dei tipi in tutte le parti della catena, a seconda di come verranno compilati tutti insieme, ma questo è un problema risolvibile. Vorrei convincerlo a buttar giù un PoC dimostrando come un nuovo servizio chiamerebbe un semplice sproc e trasferisce i dati al client (non c'è bisogno di scrivere il codice web per utilizzarlo) e di tornare indietro, e rivedere ciò. Penso che scoprirai che fa ciò che hai già fatto in un modo che significa che il compilatore fa un carico di lavoro noioso per te.
Per quanto riguarda la riduzione della necessità di andare a Entity- > DTO- > View ... c'è molta complessità nel web MVC che è stato messo lì perché Ruby on Rails lo ha fatto in quel modo, e tutti dicono che MVC è un grande modo per dividere il tuo codice. Il mio punto di vista personale è che MVC all'interno dello stesso livello sta semplicemente sovrastimando il problema (potrebbe essere utile se si ha solo quel livello che parla al DB, non se si dispone già di un buon design 3 soluzione di livello). Se si dispone già di un servizio Web e di un livello DB a cui si accede tramite sprocs, l'operazione è già stata eseguita correttamente, non è necessario replicare questa architettura nel server Web! Quindi sì, rimuoverei il codice di visualizzazione Web per renderlo il più semplice possibile.