Ist es eine schlechte Übung, EF-Entitäten Funktionalität mit partiellen Klassen hinzuzufügen?

8

Ich baue eine kleine Timing-Anwendung, die das MVVM-Muster verwendet, und verwende das Entity-Framework für die Persistenz. In diesem Stadium ist meine Logik ziemlich dünn, da ich nur ein paar Berechnungen und Aggregationen mit verwandten Daten durchführen muss. Im Moment habe ich diese implementiert, indem ich sie in eine Teilklasse der Entitätsklasse geschrieben habe.

Zum Beispiel:

%Vor%

Ist es eine schlechte Übung, zusätzliche Logik direkt auf die Entity-generated-Klassen zu setzen? Soll ich für diese Logik eine andere Domain-Ebene erstellen?

    
guhou 01.08.2010, 08:30
quelle

3 Antworten

10

Du tust genau das, wofür teilweise Klassen entworfen wurden; Hinzufügen relevanter Logik zu einer Code-generierten Klasse, ohne den Vererbungsbaum zu zerlegen. Mach weiter so.

Zusatz:

Von einer Seite in der Schrift aller Stammeskenntnisse Wikipedia (Hervorhebung hinzugefügt):

  

Der Zweck von Teilklassen ist es,   Zulassen, dass sich die Definition einer Klasse überspannt   über mehrere Dateien. Es ist   besonders nützlich für:

     
  • Sehr große Klassen (wo es mühsam ist, mit einem Editor zu navigieren)   durch eine einzige Datei)
  •   
  • Trennung von Anliegen ähnlich wie aspektorientierte Programmierung   aber ohne zusätzliche Werkzeuge. Ein   Beispiel ist unten gezeigt.
  •   
  • Es mehreren Entwicklern erlauben, gleichzeitig an einer einzigen Klasse zu arbeiten   Zeit ohne die Notwendigkeit für später   Zusammenführen von Dateien in der Quellcodeverwaltung.
  •   
  • Zulassen einer Trennung zwischen der Klassenschnittstelle und der   implementierungsbezogene Definitionen   (Separate Definitionen der Öffentlichkeit   und private Teile)
  •   
  • Erleichterung des Schreibens von Code-Generatoren, z. B. von visuellen Designern.   Dies ist vielleicht das nützlichste   Grund. Es ist eine Herausforderung, sich zu entwickeln   Codegeneratoren, die das verwalten können   generierter Code, wenn er platziert wird   der vom Menschen geschriebene Code:      
    • Benötigt viel Parsing von unnötigem Code, nur um einen zu finden   Ort zum Einfügen des generierten Codes.   Das Ändern des Codes ist ebenfalls ein Problem.   Schlecht geschriebene Generatoren halten die   potentielles Risiko, das Ganze zu beschädigen   Datei.
    •   
  •   

Verwenden Sie partielle Klassen, den Code   Generator verarbeitet eine separate Datei,   und wird so von allen gelindert   oben genannte Probleme.

    
kbrimington 01.08.2010, 08:34
quelle
2

Ich muss zugeben, dass ich das für POCOs getan habe und es sehr produktiv gefunden habe. Andere häufige Anwendungen

  • Vollständiger Name = Vorname + "" + Nachname
  • KostenIncl = Excl + Tax
  • Manchmal können auch Summen in untergeordneten Entitäten aggregieren (z. B. InvoiceTotal = Summe aller LineItem.Totals)

usw.

Es gibt einige Einschränkungen

  • Wenn Sie diese Entitäten direkt über die Verbindung senden (z. B. WCF oder ASMX), stellen Sie sicher, dass sie nicht als Serializable / DataMember markiert sind, da sie die Serialisierung ohne einen Setter
  • nicht bestehen
  • Und wenn Sie dies nicht tun (z. B. wenn Sie sie über die Leitung oder für MVVM-Zwecke abbilden), müssen Sie den Aufwand duplizieren
  • Bearbeiten: Laut Stephens Kommentar wird die Verwendung einer abgeleiteten Eigenschaft in einer LINQ-Abfrage (die SQL trifft) fehlschlagen (da sie nicht SQL zugeordnet werden kann).
StuartLC 01.08.2010 08:51
quelle
0

Es ist nicht schlecht, die partiellen Klassen der Entitäten zu verwenden, wenn Sie das Entity Framework verwenden. Sie müssen jedoch nur sicherstellen, dass Sie Geschäftslogik nicht mit Datenzugriffslogik in den Mitgliedern der partiellen Klassen mischen. Andernfalls wird es schwierig sein, Unit Test Code ohne Verbindung zur Datenbank zu schreiben.

Das Beispiel BookLibrary des WPF-Anwendungsframeworks (WAF) zeigt, wie Eine WPF-MVVM-Anwendung könnte aussehen, wenn die Domänenebene EF-Entitäten verwendet.

    
jbe 11.08.2010 19:39
quelle

Tags und Links