Ist das eine gute Idee, ViewModel genauso wie Model hinzuzufügen?

Ich habe folgende Ebenen in meiner Lösung:

1. App.Domain
2. App.Service
3. App.Core (vielleicht nennst du diese App.DataLayer)
4. App.Web

Software Design Pattern ist nicht meine Frage, ich habe folgendes Model in Domain

public class Foo {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Ich möchte dieses Modell in der Ansicht verwenden (z. B. auf der Startseite) UND ich möchte es verwenden Id, Name & Value. Wenn ich also ViewModel erstellen möchte, füge ich Folgendes hinzu:

public class FooViewModel {
    public int Id {get;set;}
    public int Name {get;set;}
    public int Value {get;set;}
}

Also, ist das eine gute Idee? oder einfach Foostatt verwenden FooViewModel?

Dies mag zunächst wie eine Verletzung der DRY-Regel aussehen, aber ich würde argumentieren, dass "ähnlicher und sogar identischer Code" nicht unbedingt "Wiederholung" ist, wenn er etwas anderes tut oder sich unabhängig ändern kann. Und im Fall von Ansichtsmodellen definiert der Code, was der "Kunde" sieht, nicht unbedingt die Entitäten und Operationen, über die das Unternehmen spricht. Daher werden dem Client oder der Benutzeroberfläche häufig Modelle angezeigt, die "zufällig identisch" sind. Sie können entweder die Geschäftsregeln und -bedingungen oder die Endbenutzerterminologie unabhängig voneinander ändern.

Also, ich würde die Frage an Sie zurückdrehen. Wenn sich die Domäne ändert, können die Clients der Version 1 die alten Schnittstellen weiterhin verwenden? Werden Sie jemals Begriffe oder Vorgänge in der Benutzeroberfläche anzeigen, die nicht zu den "Kerngeschäftsregeln" gehören? Und umgekehrt?

Diese Art von Fragen im Hinterkopf, wenn die "Funktion" Ihrer Ansicht ausschließlich darin besteht, das zugrunde liegende Domänenmodell zu offenbaren, ja, dies scheint die DRY-Regel zu verletzen.

_{Bedenken Sie auch, dass das Anzeigen einer Ansicht, die sich bei Modelländerungen natürlicher ändert, auch in einigen Sprachen mit Elementattributen und Reflexion möglich ist. (Oder mit weniger Wiederholungen durch andere Meisterleistungen der Klugheit ... Aber "Klugheit" kann die Wiederholung, die sie Ihnen erspart, oft nicht rechtfertigen.)}

Ich hätte ein Ansichtsmodell, das nur eine Eigenschaft enthält, eine Foo-Instanz. Auf diese Weise verletzen Sie DRY nicht gemäß einer Definition davon, wenn sich Foo ändert, Ihr Ansichtsmodell die Änderung automatisch sieht und Sie sich von einer direkten Bindung des Ansichtsmodells an das Modell frei lassen.

Wenn die Ansicht morgen etwas anderes als das Foo anzeigen muss, können Sie einfach eine neue Eigenschaft hinzufügen, und die Absicht Ihres Ansichtsmodells ist weiterhin klar, es enthält ein Foo und etwas anderes, das Sie nicht haben eine Mischung von Eigenschaften von Foo mit nicht verwandten anderen Eigenschaften.

Ich würde Ihr Ansichtsmodell nicht als FooViewModel betrachten, sondern als das, was in der Ansicht angezeigt werden soll. Wenn nur ein Foo angezeigt wird, enthält das Ansichtsmodell eine Eigenschaft, ein Foo.

Ich bin mir nicht sicher, ob ich das klar erklärt habe. Wenn nicht, lass es mich wissen und ich versuche es umzudrucken, wenn ich wach bin!

Ich würde sagen, dass die Verwendung FooViewModelauf diese Weise das DRY-Prinzip verletzt. Wenn Sie eine Änderung an vornehmen müssen, müssen FooSie auch eine Änderung an vornehmen FooViewModel. Ich denke, Sie wären besser bedient, Foowenn Sie einfach das Modell für Ihre Ansicht verwenden würden. Ich würde ein Ansichtsmodell in Betracht ziehen, wenn Sie Dinge von Foo und etwas anderes anzeigen müssen. Angenommen, Sie müssen einige Informationen von Foound auch von rendern Bar.