[WCF] DB-Model, DTO, Model für die UI (MVVM, ASP.Net MVC)...

[asc]

Ausgangssituation (reine Planung): Mehrschichtige Anwendung, bei der die wesentliche Logik auf den Server läuft (Hintergrund ist eine möglichst starke Gemeinsame Codebasis zwischen verschiedenen Oberflächen [WPF, WinRT, WP8, ASP.Net]). Nun habe ich mir diverse Beispiele/Bücher/Tutorials angesehen wie man unter C# eine solche Anwendung strukturiert, mit gänzlich unterschiedlichen Annahmen.

Viele reichen z.B. das Datenmodel der Datenbank direkt als Model der Oberfläche durch, was imho ein wenig problematisch ist. Zum einen ist das Datenmodel (Bei mir EF Code First) nicht unbedingt in jeder Hinsicht das, was an der Oberfläche verwendet wird (Die Daten könnten ggf. etwas anders strukturiert sein), zum anderen ist mir hier die Abhängigkeit etwas zu extrem, wenn eine Änderung erfolgt (vielleicht sogar etwas von der konkreten Datenbank abhängig ist).

Anderseits frage ich mich ob das trennen der Daten in drei Bereiche: Datenmodel, Datentransferobjekte (WCF DataContract) und dem Model was die Oberflächen angeht nicht doch etwas zu extrem ist, anderseits kann der DataContract keine Logik enthalten, und zumindest ein paar virtuelle oder akstrakte Methoden finde ich doch praktisch.

Beispiel: Wir haben ein zugrundeliegendes Objekt auf den viele allgemeine Zuordnungen gemacht werden, und bei dem die Id für spezielle Objektbezogene Rechte entscheidend ist. Dieses Basisobjekt hat aber keine Texteigenschaften die man für eine allgemeine Darstellung verwenden kann (z.B. in einer Auswahlliste), man könnte dieser aber eine abstrakte Methode geben da jedes davon abgeleitete Objekt zumindest irgendeine Eigenschaft (oder mehrere) hat, die zu einer einfachen Bereichnung herangezogen werden könnten (z.B. eine Person mit "<Nachname>, <Vorname>"...).

Ich könnte natürlich auch dem DTO einige Eigenschaften geben, die es so nicht wirklich gibt (Property "AnzeigeKurz"/"AnzeigeLang"), halte dies aber für unnötige Dopplung von Daten...

Verpackt man wirklich in einen solchen Fall ein Objekt mehr oder weniger in drei verschiedene Einheiten? "DB Modell" <-> DTO <-> "Model für UI"? Oder ist dies das klassische schießen mit Kanonen auf Spatzen? Die Trennung in DB-Modell und UI-Modell halte ich wegen Unterschieden schon für sinnvoll, gerade weil es viele Fälle gibt, wo ich ein "aufbereitetes" Objekt habe, das sich auf DB-Seite aus mehreren zusammensetzt, oder bestimmte schwergewichtige Eigenschaften nur an manchen Stellen brauche (z.B. lange Memofelder wie Anmerkungen etc.).

Ich möchte die Anwendung von Anfang an möglichst sauber haben, zumal sie nicht wirklich klein ist, und langfristig massiv erweitert werden soll (Die Vorlage sind zwei C++ Builder-Programme mit zusammen etwa 750.000 Codezeilen, die stark Datenorientiert arbeitet).

Lieber nehme ich hier etwas mehr Arbeit in Kauf bevor ich mir später Probleme einhandel, aber ich frage mich auch, ob ich an manchen Stellen dann nicht in ein "Overengenieering" verfalle.

[hustbaer]

DB und DTO trennen macht IMO auf jeden Fall Sinn -- sehe ich ähnlich wie du. Das zu koppeln wäre unsauber und gefährlich.
Ich würde das einfach mal als "muss" festsetzen.

Wenn die Verwendung des EF auch "muss" ist, dann bleibt eh keine Wahl mehr, dann müssen da zwei Klassen programmiert werden.
Sonst, ohne EF, könnte man evtl. stellenweise die Daten direkt aus den Tabellen in die DTOs schaufeln und umgekehrt. (Wobei das vermutlich auch recht schnell unsauber wird, also wird es so oder so nicht ausbleiben dass man für jede DB-Entity eine Klasse bastelt.)

Was die Trennung DTO/UI angeht... pfuh. Weiss nicht. Macht vermutlich auch Sinn. Wobei ich mir auch immer denke "is ja irre, alles 3x machen, das muss ja einfacher gehen".