Struttura della classe per Entity Framework

Question

Struttura della classe per Entity Framework

#1 da (1 voti)

2

Sto usando EF (prima Code) e vorrei isolare le proprietà dai metodi (molti dei metodi fanno riferimento ad altre librerie che non voglio che il mio progetto di database debba fare riferimento).

Ad esempio, supponiamo di avere questa classe

public class Person
{
  public string Name { get; set; }
  public void SayName()
  { 
    SomeExternalAssembly.Say(Name)
  }
}

Perché SomeExternalAssembly non ha nulla a che fare con il database Mi piacerebbe spostare il metodo SayName su un altro assembly mantenendolo in una "versione" di Person .

Nel mio mondo ideale (che non funziona ed è probabilmente una cattiva idea) erediterei Person in DerivedPerson e poi lo rimando a Person quando ho bisogno di salvarlo nel DB. Mentre posso eseguire il cast, quando tento di aggiungerlo al DB, ottengo un System.InvalidOperationException: Mapping and meta data information could not be found for EntityType 'DerivedPerson' .

Poiché non ha funzionato, la soluzione migliore che riesco a fare è aggiungere una proprietà Person alla mia nuova classe:

public class PersonB
{
  public Person Data;
  public void SayName()
  { 
    SomeExternalAssembly.Say(Data.Name)
  }
}

Mentre funzionerebbe, sto cercando qualcosa di un po 'più pulito (e idealmente meno modifiche al codice). Il prossimo pensiero che ho avuto è stato quello di andare con l'ereditare, quindi aggiungere un metodo di conversione utilizzando la riflessione.

Qualcuno ha un approccio migliore?

c# design-patterns entity-framework

posta MikeH 03.08.2015 - 21:49

fonte

1 risposta

Leggi altre domande sui tag c# design-patterns entity-framework

Esiste una nozione ben definita di "prima" e "dopo" nelle macchine a stati finiti? Come l'integrazione di sistema avviene con un ESB?

score 1 · Answer 1

Se sei sicuro al 100% di voler "imbullonare" i metodi su queste tabelle / classi EF, basta aprirli come classe parziale in un file separato e aggiungere i metodi necessari:

// location -> /EntityPartials/Person.cs

public partial class Person
{
  public void SayName()
  { 
    SomeExternalAssembly.Say(this.Name); 
    // 'this.*' above is optional but could be used to quickly identify EF data-properties.
  }
}

Per la cronaca, NON consiglierei l'uso di parziali come questo che hanno bisogno di parlare con componenti esterni che richiedono qualsiasi tipo di stato di classe, dal momento che non si può controllare facilmente i costruttori in EF e quindi perdere il potere di iniettare dipendenze. Tuttavia, ho un progetto LINQ-2-SQL che fa un sacco di uso del pattern sopra per fare varie cose come la formattazione di stringhe, la validazione condizionale, ecc.