Eigene partial Klassen aus Entity Framework - wie handeln? (WinForms)

[OctoberSwimmer]

Schönen Abend zusammen,

ich verwende EF über DB-First.
Für die verwendeten Tabellen gibt es dann ja automtisch eine partial class tblFoo.

Um für die Tabellen weitere Eigenschaften hinzuzufügen, kann ich ja einfach eine weitere Klasse partial class tblFoo machen.
Soweit so gut ... nun würde ich gerne wissen, wie ich das "sauber" im Projekt mache.

Also wie benenne ich die Klasse(datei) sinnvoll?
Für jede Tabelle eine eigene Klassendatei?
Oder wo bringt man die Erweiterung sinnvoll unter?

Kann ich außer Eigenschaften der Klasse (Tabelle) dann auch weitere Funktionen zuordnen - hab ich noch nicht selbst versucht, nur grundsätzlich ob dies möglich ist?

Ich hoffe, es ist einigermaßen verständlich?! Danke Euch!

[Ralf Jansen]

Also wie benenne ich die Klasse(datei) sinnvoll?
Für jede Tabelle eine eigene Klassendatei?

Für den Namen kenne ich keinen sinnvollen Best Practise. Üblicherweise nenne ich sie wie die Klasse mit angehängten Aufgabengebiet dieses Klassenteils also in etwas 'Klasse.Aufgabe.cs' Das macht hier aber vermutlich wenig Sinn da du ja kein andere eindeutige Klassendatei von EF hast. Die EF Klassen sind ja auch in eine einzige Datei generiert. Es hilft also nicht deine partiellen Klassen auf einzelne Dateien zu verteilen um sich zu orientieren.
Ich würde also alle Extensions deine Models in eine einzelne andere Datei packen und einfach zum Beispiel ModelExtensions.cs nennen.

Kann ich außer Eigenschaften der Klasse (Tabelle) dann auch weitere Funktionen zuordnen - hab ich noch nicht selbst versucht, nur grundsätzlich ob dies möglich ist?

Klar. Hinzufügen geht immer. Das Verhalten des generierten Codes ändern aber nicht.

Edit: Ich sehe gerade das du in der Überschrift Winforms erwähnst. Dir ist klar das eine Form in Winforms auch eine partielle Klasse ist oder? Stell dir vor in der dürftest du nur Properties benutzen

[fanderlf]

An dieser Stelle wäre vielleicht auch drüber nachzudenken nicht die generierten Klassen durch die komplette Applikation zu reichen, sondern nochmal eine Schicht zu bauen die die Klassen auf POCO Klassen mappt die mit EF gar nichts zu tun haben. Ich kenne leider die generierten Klassen vom EF nicht, aber wenn dort technische Abhängigkeiten zum Entity Framework existieren würde ich dringendst dazu raten.
Dazu kommt noch dass man dann den Kern der Anwendung, ich vermute dass die Businesslogik in Deinen Erweiterungen Platz finden würde, dann auch an einer Stelle zentral gehalten werden würden und nicht über mehrere Partials verteilt sind. Zum Mapping kann man z.B. Automapper verwenden, damit man nicht mehr ganz so viel Mapping Code schreiben muss. Natürlich muss insgesamt auch berücksichtigt werden ob es sich hierbei um einen schnellen Prototyp oder eine große Businessanwendung handelt, aber das muss ich ja eigentlich bei fast jeder Entscheidung berücksichtigen.

[OctoberSwimmer]

Ich würde also alle Extensions deine Models in eine einzelne andere Datei packen und einfach zum Beispiel ModelExtensions.cs nennen.

Danke für den Tipp ... so hab ich es nun (vorerst) gemacht.

@fanderlf
Danke für den Hinweis mit POCO - hab mich bisher noch nicht damit auseinander gesetzt bzw. verstehe das auch noch nicht so recht.
Falls ich das kapieren sollte, werde ich ggf. meinen obigen Ansatz wieder verwerfen.