2017-02-20 6 views
0

Ich erstelle eine mehrstufige Anwendung in .Net/C#/EF6/WPF/WCF.Wo kann die Änderung des Entitätsstatus in einer mehrstufigen Anwendung verwaltet werden?

Das Backend ist eine MySQL-Datenbank mit einem Entity-Framework-Layer für den Zugriff auf die Datenbank. Ich habe eine Geschäftslogikebene und eine Fassadenebene, um den Dienst verfügbar zu machen.

Auf der Clientseite ein WPF/MVVM-Client.

Ich habe 3 Modelle, eine für den Client ("Domäne anzeigen"), eine für das Back-End von Entität Framework ("DB-Domäne") und eine dto-ähnliche für die Dienste generiert.

Auf der Clientseite I Entitätsstatus Änderungen verfolgen, kopiert ich im Grunde die EntityState Enum aus System.Data und den Zustand gesetzt, wenn eine Eigenschaft geändert wird oder wenn eine neue Einheit geschaffen wird.

Zum Beispiel, einer meiner Dienste expose Add(Entity e) und Update(Entity e).

Sollte nehme ich die Entscheidung eine oder andere Methode auf dem Client zu nennen (er weiß, ob der Staat Added oder Modified ist) oder sollte ich eine einzige Methode AddOrUpdate(Entity e) genannt aussetzen und lassen Sie das Backend entscheiden, ob es sich um eine neue oder Update des Unternehmens ?

Was ist der beste Ansatz dafür? Sollte ich diesbezüglich eine Entscheidung auf der Client- oder Backend-Seite treffen?

+0

nehmen, wenn Sie Multi-Layer-Anwendung und eine Datenzugriffsschicht Sie sollten den Status der Zeilen in der Datenzugriffsebene validieren und steuern, aber in entityframwork benötigen Sie keinen Steuerelementstatus der Entität (wie den Datensatzstatus), und Sie können Änderungen speichern, um alle Änderungen zu übernehmen, aber wenn Sie sie kontrollieren müssen der Staat, den Sie es in der Fassade steuern können und dann entscheiden, welche Methode des Datenzugriffs oder der Regelschicht am meisten Anruf ist –

+1

Für mich ist eine wichtigere Frage, ob ein Klient Änderungsverfolgung überhaupt tun sollte. Technisch gesehen hat der Client immer veraltete Daten, so dass jeder Datenpunkt möglicherweise "modifiziert" wird, selbst wenn der Client das nicht weiß. Nur der Server ist darauf ausgerichtet, den aktuellen Status zu vergleichen. Außerdem kann der Dienst nicht jedem Client vertrauen, dass er es richtig macht, daher muss er Änderungen immer überprüfen/validieren. –

+0

Sie haben zwei Möglichkeiten, um den Status nicly 1 zu steuern.Sie können den Zustand in der Fassade steuern und dann, wenn Sie den Regel-Layer und die Regel aufrufen müssen, rufen Sie den Datenzugriffs-Layer auf und wenn Sie einen Fehler in den Präsentations-Layer zurückgeben müssen, müssen Sie nicht zur Regel- oder Datenzugriffs-Ebene gehen Sie können ein HTTP-Modul verwenden, um diese Art von Situation zu überprüfen. In diesem Fall haben Sie keinen gefälschten Service-Anruf ... –

Antwort

1

Nicht sicher, warum der Client den Status eines Objekts kennen/handhaben soll.
Ihr Problem wird wahrscheinlich verursacht, weil Sie die "Entity" -Klasse in beiden Methoden wiederverwenden.

Ich glaube, Sie so etwas wie dieses verwenden:

Add(InputResource e) 
Update(UpdateResource e) 

Keine der oben Genannten sollten * einen „Staat“ Eigenschaft.
Die "InputResource" sollte keine ID/Primärschlüssel haben

Ich denke, der obige Ansatz ist sauberer, aber es hängt von Ihren Bedürfnissen ab.
Wenn Sie mit dem "AddOrUpdate" gehen möchten, denke ich immer noch nicht, dass das Hinzufügen eines Zustands eine gute Idee ist.
Sie können die Id-Eigenschaft überprüfen, wenn es eingestellt ist, ist es ein Update, wenn es nicht ein Hinzufügen ist

* Natürlich spreche ich über Ihre öffentliche API.
intern auf dem Server (BusinessLayer-Datalayer) Sie können eine Lösung, die Elemente basierend auf ihren Zustand behandelt, aber ich glaube nicht, dass Sie diesen

Verwandte Themen