È ragionevole usare POCO che ereditano da DTO?

Farei quelli in un ordine diverso-
In primo luogo, mapperei il mio dominio aziendale e individuerei il miglior design per risolvere il mio problema aziendale. Questo ti darà il tuo dominio.

Quindi, idealmente in una mentalità completamente diversa, pensa ai requisiti del tuo lato client e dell'interfaccia utente; quali dati verranno visualizzati e come? Questo ti darà i tuoi DTO.

A volte, le DTO ricomperanno abbastanza da vicino le tue classi di dominio. Altre volte - non lo faranno.
La mappatura tra di loro può essere facilitata con strumenti automatici come l'automapper.

In generale, sono sempre favorevole a separare completamente le tue classi di dominio e DTO. Il nocciolo della questione sono le classi di dominio e le DTO sono create per risolvere diversi problemi . Pertanto, non sono correlati da una relazione 'is-a' che è ereditaria.

Manterò ognuno di questi insiemi di classi separate (quelle per l'interazione WFC, quelle per il database e quelle per la vista ... il modello di vista). A prima vista sembrerà certamente come se stessimo duplicando il lavoro, il che va bene. Il vantaggio è che se alcune delle classi devono essere riutilizzate da qualche altra parte, allora sono separate e sono più portabili.

A volte avrai viewmodels o DTO in cui i nomi dei campi e i tipi di dati corrispondono esattamente. In questo caso, utilizza qualcosa come Automapper per mappare da un oggetto a un altro. Ciò ti consente di mantenere le cose separate mantenendo il tuo codice pulito e rendendo l'integrazione molto più semplice.