Gemeinsame Modelle für WPF und ASP.NET MVC

Question

Ich werde zwei Anwendungen erstellen. Einer von ihnen in WPF und der zweite in ASP.MVC. Ich habe mich entschieden, einen Webservice zu erstellen, der eine Ebene zwischen der Datenbank und meinen Anwendungen darstellt. Ich möchte keine Entitätsmodelle in meinen Apps verwenden. Ich möchte leichtgewichtige Modelle erstellen, sie an den Webservice senden und sie dann in die Entitätsmodelle übersetzen. Meine Frage ist, wie man ein gemeinsames Modell für WPF und MVC erstellt? Ich weiß nicht, wie ich das machen soll, weil ich die Datenanmerkungsattribute für MVC verwenden und auch die INotifyPropertyChanged-Schnittstelle für WPF implementieren möchte. Es wird auch andere Dinge geben, denke ich. Gibt es einen guten Ansatz dafür? Oder es ist unmöglich?

Answer 1

Nun, in erster Linie ist nichts falsch mit Exponierung Klassen außerhalb der DAL. Sie sind nur Klassen. Es gibt nichts besonderes an ihnen. Was macht sie Datenbank-Zeug ist ihre Einbeziehung in eine DbContext-Klasse, und Sie könnten tatsächlich alle Anmerkungen und andere Konfiguration in den Kontext mit fließenden Config bewegen und haben unberührte Klassen ohne irgendeine Art von Einfluss von außen in ihnen.

Außerdem gibt es eine Tendenz, sowieso zu viele Konfigurationen zu Entity-Klassen hinzuzufügen. Sie sollten nur Dinge haben, die wichtig sind auf einer Datenbankebene. Dinge wie [EmailAddress], die angeben, wie eine Eigenschaft beim Post validiert werden soll, sind für eine Entitätsklasse ungeeignet.

Das heißt, der Ort, um Dinge wie [EmailAddress] und andere Sicht-spezifische Dinge zu setzen ist auf Ansicht Modelle. Das sollte den Rest Ihrer Verwirrung ziemlich aufklären. Müssen Sie INotifyPropertyChanged implementieren? Tun Sie das mit einem Ansichtsmodell. und mappe deine Entitätsdaten zu/von ihr.

Tun Sie es einfach nicht, wie ich einige Leute gesehen habe, und erstellen Sie eine DTO-Klasse, die im Grunde eine exakte Kopie Ihrer Entitätsklasse ist, nur um die Daten von einem Ort zu einem anderen in Ihrer App zu übertragen. Das ist nutzlos und fügt nur zusätzliche Dinge hinzu, um die Wartung und zusätzliche Arbeit zu leisten, die Ihre App ohne Nutzen ausführen muss. Die Entitätsklasse ist ein DTO. Geben Sie es von Ihrem Dienst zurück und ordnen Sie es dann Ihrem Ansichtsmodell zu. Erledigt.

Um das letzte Bit zu verdeutlichen, sollten die Klassen, die für Ihre WPF/MVC-Apps wichtig sind, ihre Ansichtsmodelle sein, und diese werden nur für die App verwendet. Die Logik für das, was in WPF benötigt wird, und das Zuordnen von Entitätsdaten zu/von diesem gehört zur WPF-App. Es wäre 100% unangemessen, Code-Erzeugungs-Klassen-Instanzen zu haben, die direkt in einer WPF-Anwendung verwendet werden, um von einem Dienst erzeugt zu werden, der mit dem Erhalten der Daten an erster Stelle befasst sein soll. Dies wäre eine Verletzung des Grundsatzes der einheitlichen Verantwortung. Lass jedes Ding tun, wozu es entwickelt wurde. Bewahren Sie WPF-Code mit WPF-Code auf. Sie könnten immer noch eine Bibliothek haben, die die Zuordnung zwischen der Datenschicht und Ihren WPF-Ansichtsmodellen behandelt, aber das sollte eine separate Sache sein, die nur eine Abhängigkeit in Ihrer WPF-App darstellt.