Dipende. La classe Person è un semplice vecchio oggetto C # quando è istanziata? Non ho molta familiarità con EF, ma in altri framework come Doctrine o Hibernate puoi fare affidamento sul framework per creare un'istanza e restituire un semplice oggetto vecchio che non contiene alcuna magia di framework.
Se questo è il caso, e non c'è nulla riguardo all'oggetto o alla classe che lo lega al framework di persistenza come una gerarchia di ereditarietà, allora sì, penso che sia perfettamente ragionevole restituirlo da un repository.
Dai commenti in basso, aggiungerei anche quanto segue. Mi rendo conto che alcune di queste idee potrebbero nuotare controcorrente un po '.
L'idea di code-first vs. db-first è fondamentalmente una reliquia inerente all'età di EF e all'evoluzione delle best practice intorno agli ORM. In particolare, con DDD, devi sempre scegliere il codice e utilizzare solo db-first quando hai un DB legacy che devi integrare con un nuovo livello dominio / applicazione. In questo senso, quando utilizzo DDD, ritengo che le classi EF db-first dovrebbero costituire l'input per il livello anti-corruzione del tuo dominio.
Tuttavia, con il paradigma code-first il problema è diverso. In questo scenario, con framework ORM come EF, non vuoi mescolare il tuo framework di persistenza con il tuo codice di dominio e quell'istinto ha perfettamente ragione.
Tuttavia solleva il problema di ciò che costituisce "mixing" e se utilizzare o meno vecchi oggetti che il framework sa come idratare dal database è sufficiente per separare le preoccupazioni. La mia opinione è che se gli oggetti idratati sono semplici vecchi oggetti che possono essere indipendenti dal framework, allora si stanno ancora separando le preoccupazioni. La ragione di ciò è che gli oggetti restituiti dai repository sono estratti dall'ORM: il codice client dei repository non può dire la differenza se il semplice oggetto vecchio proviene dall'ORM o qualche altra cosa come una fabbrica o un altro meccanismo di persistenza, come una cache.
Alcuni framework potrebbero richiedere che le tue classi code-first ereditino da una classe genitrice fornita dal framework, o potrebbero usare reflection o qualche altro dinamismo run-time per aggiungere metodi alle tue classi code-first, ad esempio per supportare un API in stile ActiveRecord. In questi casi, anche con il codice in primo luogo, direi che probabilmente è bene avere le tue classi di dominio semplici. Ma stai aggiungendo complessità per l'astrazione extra.
Alcuni framework ORM, probabilmente EF, forniranno classi di tipo proxy per entità correlate. Ad esempio, se si dispone di una classe di entità Employee che compone una classe di entità Person e sono connesse l'una con l'altra tramite una relazione di chiave esterna nel database, quando si ottiene un oggetto Employee dal repository, a seconda del tipo della query del database è stata utilizzata e la configurazione della relazione, i dati relativi all'entità Person verranno caricati pigramente dal database. In tal caso, quando si chiama getPerson () sull'oggetto Employee, viene restituito l'oggetto proxy anziché l'oggetto Persona reale e l'oggetto proxy risulterà errato nei dati Persona la prima volta che si tenta di leggere i dati dall'oggetto.
Personalmente non ritengo che l'uso di oggetti proxy in questo modo, anche se fa parte della magia del framework, dovrebbe causare la creazione di oggetti di dominio separati. Di nuovo, se dovessi scambiare gli ORM o usare un diverso archivio di persistenza, i repository potrebbero incapsulare / delegare tutto ciò. Le preoccupazioni sull'accoppiamento della struttura di persistenza e del modello di dominio possono essere alleviate nei repository.