Devo usare modelli separati per dominio ed EF?

Question

Scenario: Sto scrivendo un programma che gestisce la generazione di report.

Ho il report memorizzato in un database, mappato su un modello EF. Esistono alcuni campi non di database (ad esempio alcuni campi vengono calcolati automaticamente in base agli altri campi presenti nel db). Avrebbe senso avere una classe che si mappasse esclusivamente al DB, e un'altra classe che prendesse quell'informazione e in aggiunta avesse gli altri campi di calcolo?

cioè una classe di esempio per interagire con il database codefirst sarebbe

public class Report{ 
    public int CategoryOneSeverity {get; set;} 
    public int CategoryTwoSeverity {get;set;} 
    public string Title {get;set;} 
} 

Avrebbe senso per fare un'altra classe, come:

public class ReportModel{ 
    public int CategoryOneSeverity; 
    public int CategoryTwoSeverity; 
    public string Title; 

    public int RiskRating{ 
     get{ return CategoryOneSeverity + CategoryTwoSeverity; } 
    } 
}  

O dovrebbe la proprietà RiskRating essere in EF modello.

Answer 1

Sì, credo assolutamente che dovresti avere classi diverse per modellare il tuo dominio rispetto al tuo DB. A meno che la tua applicazione non sia banale, se provi a mappare direttamente gli oggetti del tuo dominio, devi sempre modificarli per far corrispondere a ciò che ti serve la tua struttura dati, ed eventualmente esporre cose che non vuoi esporre. Consideralo come una violazione del principio di Responsabilità Unica; la tua classe ha due ragioni per cambiare se la fai diventare oggetto di dominio e mapparla direttamente. Uno è in risposta alla modifica dei requisiti aziendali, l'altro è in risposta alla modifica dello schema di archiviazione dei dati.

Answer 2

"Avrebbe senso di avere una classe che mappa unicamente al DB e un'altra classe che prende queste informazioni e ha le altre campi di calcolo in più?"

Molto probabilmente sì. Generalmente creo una nuova classe suffissa con "ViewModel" come HumanResourcesReportViewModel se la mia classe di entità fosse HumanResourcesReport.

C'è un sacco di variazioni su come usare ViewModels, e potremmo entrare in un dibattito pedante sulla terminologia, ma concettualmente, prendere la tua entità e creare una nuova classe con quei dati più qualsiasi informazione aggiuntiva necessaria per elaborare il report. In questo caso la generazione del report è in un certo senso la vista del modello MVC, quindi non penso che sia offensivo chiamare la classe che detiene i dati come ViewModel.

Answer 3

Stai utilizzando il codice prima di DB First?

È possibile avere campi calcolati automaticamente nel modello, che non sono mappati ai campi nel database.

Dipende anche dalla tua architettura. Se si utilizza DB per la prima volta, l'aggiornamento del modello EF aggiornerà le classi EF, perdendo i campi associati. Nello scenario DB-First, un'alternativa sarebbe utilizzare la classe del modello EF come classe base e ereditarla per la classe del report.

public class ReportModel 
{ 
public int CategoryOneSeverity; 
public int CategoryTwoSeverity; 
public string Title; 
} 

public class ReportClass : ReportModel 
{ 
public int RiskRating 
{ 
get{ return CategoryOneSeverity + CategoryTwoSeverity; } 
} 
}