Wir haben eine Diskussion darüber geführt, ob Domain Objects in unseren Views verwendet werden sollen (asp.net mvc 2) oder ob für jede View, die Daten benötigt, ein ViewModel gesendet wird?
Ich habe mich gefragt, ob irgendjemand irgendwelche Vorteile / Nachteile zu diesem Thema hat, über die sie etwas aufklären könnten?
Danke
Ich möchte meine Domain-Objekte von meinen Ansichten trennen. Soweit es mich betrifft, sind meine Domain-Objekte nur zum Zweck der Darstellung der Domain der Anwendung, jetzt wie die Anwendung angezeigt wird.
Die Präsentationsschicht sollte keine Domänenlogik enthalten. Alles, was sie anzeigen, sollte von ihrem Controller vorher festgelegt werden. Um sicherzustellen, dass dies immer eingehalten wird, ist sicherzustellen, dass die Ansicht nur diese abgeflachten ViewModels erhält.
Ich habe eine ähnliche Frage
Ich denke, dass es Vorteile gibt mit einem anderen Design in der Domäne als in der Präsentationsebene. So konzeptionell bist du eigentlich Blick auf zwei verschiedene Modelle, eins für die Domain - Ebene und eine für die Präsentationsfolie. Jedes der Modelle ist für ihren Zweck optimiert .
Wenn ich die Domain-Objekte für Customer & gt; Sales & gt; Dispatch Address , dann möchte ich mich nicht mit dem Objekt Traversal in meiner Sicht befassen müssen. Ich erstelle ein flachgelegtes Ansichtsmodell, das alle Eigenschaften enthält. Wenn Sie das hervorragende Open-Source-Projekt AutoMapper verwenden, gibt es fast keine zusätzliche Arbeit beim Mapping zu und von diesem vereinfachten Ansichts- / Präsentationsmodell.
Warum sollten Sie außerdem ein vollständiges Domänenobjekt an eine Ansicht zurückgeben, wenn Sie eine optimierte Darstellung dieses Modells erstellen können?
Wenn Sie NHibernate oder ähnliches verwenden, sind Ihre Domain-Objekte höchstwahrscheinlich Proxies, die serialisiert werden. Sie sollten immer ein ViewModel verwenden und Ihre Domänenobjekte DTOs in Ihrem Ansichtsmodell zuordnen. Nimm hier keine Abkürzungen. Das Festlegen der Konvention wird die Schmerzen lindern, die Sie später erleiden werden.
Es ist ein Standardmuster aus einem Grund.
w: //
Es kommt darauf an. In einigen Fällen ist es in Ordnung, Instanzen von Modellklassen zu verwenden. In anderen Fällen ist ein separates ViewModel die bessere Wahl. Nach meiner Erfahrung ist es vollkommen akzeptabel, verschiedene Modelle in Ihrer Domain und in Ihren Ansichten zu haben. Oder das Domänenmodell in der Ansicht verwenden. Tun Sie, was am besten für Sie funktioniert. Machen Sie einen Spike für jede Option, sehen Sie, was funktioniert und entscheiden Sie dann. Sie können sogar für jede Ansicht (und / oder teilweise) eine andere Option auswählen.
Es wird definitiv einfache kleine Apps geben, bei denen es gut ist, dieselben Modelle über alle Ebenen hinweg zu verwenden. Im Allgemeinen wenig Formulare über Daten Apps. Aber für eine richtige Domäne sind meine Gedanken zu dem Thema, die Domänenmodelle und die Modelle getrennt zu halten, weil sie nicht wollen, dass sie sich gegenseitig beeinflussen, wenn sie geändert werden.
Wenn die Domänenlogik eine kleine Änderung benötigt, um eine neue Geschäftslogik am Back-End zu verarbeiten, möchten Sie nicht riskieren, dass Ihre Ansicht geändert wird. Umgekehrt, wenn Marketing oder jemand Änderungen an einer Ansicht vornehmen möchte, möchten Sie nicht, dass diese Änderungen in Ihre Domäne zurückfließen (Felder ausfüllen und Daten für keinen anderen Zweck aufbewahren müssen, als irgendeine Ansicht irgendwo verwendet) / p>
Ich habe momentan einen guten Vergleich, weil ich an zwei Projekten mit verschiedenen Ansätzen arbeite. Ich bin weit davon entfernt zu sagen, dass "das ist schlecht und das ist gut", weil dies in einigen Mustern geschrieben wird. Ich kenne Muster, ich mag Muster, aber ich folge ihnen nie blind, nur um richtig zu sein. Ich nutze immer das, was ich zur Erreichung der aktuellen Ziele brauche.
In der ersten Anwendung, die Domänenobjekte in Sicht verwendet, ist die Entwicklung sehr schnell. Wenige Änderungen an wenigen Stellen und Sie haben zusätzliche Eigenschaften, Formulareingaben usw. Sie kümmern sich nicht um die Ebenen, nur erweitert / ändern Sie den Code und übergeben Sie ein anderes Problem.
In der zweiten App, in der es immer ein Objekt gibt, gibt es Dutzende von Klassen, die gleich aussehen und eine Menge Konvertierungscode zwischen verschiedenen Versionen der gleichen Objekte haben. Mehr schlecht ist, dass einige Entwickler einige Logik auf "dieser Version" der Klasse machen, und andere Logik wird auf "dieser Version" gemacht. Die Entwicklung ist sehr schmerzhaft und erfordert eine Menge Tests danach. Das Ändern einer einfachen Sache erfordert viel Aufmerksamkeit und viel Code muss geändert werden. Ich mag diese App wirklich nicht, weil ich noch nie gesehen habe, dass ein Unternehmen von diesem Ansatz profitiert, zumindest während des letzten Jahres (und wir sind seit dem Jahr in der Produktionsphase). Diese App ist drei-vier mal teurer zu entwickeln und zu pflegen als die erste.
Also, meine lustige Antwort auf die Frage ist: Es kommt darauf an. Wenn du in einem Team von 10-20 Leuten arbeitest, möchtest du in die Arbeit kommen, ein paar Coffies trinken, mit einem Freund reden, ein paar einfache Dinge tun und nach Hause gehen, viele Zwischenobjekte und Conversion-Code werden dir gut tun. Wenn es Ihr Ziel ist, schnell und günstig zu sein, wenn Sie sich auf Business-Layer, neue Funktionen, schnelle Änderungen und mehr konzentrieren wollen, wenn Sie Softwaregeschäft anfassen und Ihr Projekt einlösen wollen (wir tun all diese Dinge, um sie letztendlich zu verkaufen, richtig?), wäre der zweite Ansatz wahrscheinlich besser.
Tags und Links asp.net-mvc asp.net asp.net-mvc-2