Sollte eine Dienstschicht Rückkehr Ansicht Modelle für eine MVC-Anwendung?

StackOverflow https://stackoverflow.com/questions/3002168

Frage

Sagen Sie ein ASP.NET MVC-Projekt haben und werden mit einer Service-Schicht, wie in diesem Kontaktmanager Tutorial auf der asp.net Website: http://www.asp.net/mvc/tutorials/iteration-4-make-the-application-loosely- koppelten cs

Wenn Sie Viewmodel für Ihre Ansichten haben, ist die Service-Schicht der geeignete Ort jedes Ansichtsmodell zur Verfügung zu stellen? Zum Beispiel gibt es in der Service-Layer Codebeispiel ist ein Verfahren 

    public IEnumerable<Contact> ListContacts()
    {
        return _repository.ListContacts();
    }

Wenn Sie stattdessen eine IEnumerable will, sollte es gehen in der Dienstschicht, oder gibt es irgendwo anders, dass der „richtigen“ Platz ist?

geeignetere Vielleicht, wenn Sie ein separates Ansichtsmodell für jede Ansicht mit ContactController zugeordnet haben, sollte ContactManagerService verfügen über ein separates Verfahren jedes Ansichtsmodell zurückzukehren? Wenn die Service-Schicht nicht der richtige Ort ist, wo soll durch den Controller für den Einsatz Ansichtsmodell Objekte initialisiert werden?

War es hilfreich?

Lösung

Im Allgemeinen nicht.

Ansicht Modelle sollen Informationen zur Verfügung zu stellen und von Ansichten und sollen spezifisch auf die Anwendung sein, in Bezug auf die allgemeine Domain gegenüber. Controller sollte die Interaktion mit Repositories orchestrieren, Dienstleistungen (ich einige Annahmen der Definition des Service hier mache), etc. und Griff Gebäude und Validieren Ansicht Modelle und enthält auch die Logik Blick auf der Bestimmung zu machen.

Durch undichte Ansicht Modelle in eine „Service“ Schicht, die Sie Ihre Schichten verwischen und haben nun mögliche Anwendung und Präsentation spezifische gemischt mit dem, was mit domänenverantwortungsvollen Aufgaben konzentrieren sollte.

Andere Tipps

Nein, ich glaube nicht. Die Dienste sollten nur über das Problem Domain, nicht der Ansicht, dass macht Ergebnisse sorgen. Rückgabewerte sollten in Bezug auf Domänenobjekte ausgedrückt werden, nicht Ansichten.

Gemäß dem traditionellen Ansatz oder Theorie wiese, Ansichtsmodell sollte Teil der Benutzeroberfläche Schicht sein. Zumindest der Name sagt so.

Aber wenn man zu deren Umsetzung sich mit Entity Framework, MVC, Repository etc runter, dann merkt man, etwas anderes.

Jemand hat Entity / DB Modelle mit Viewmodels (DTO erwähnt am Ende) abzubilden. Sollte dies in [A] durchgeführt werden, um die UI-Ebene (durch den Controller) oder in [B] der Dienstschicht?

Ich gehe mit Option B Option A ein nein nein aufgrund der einfachen Tatsache, dass mehrere Unternehmen Modelle miteinander zu verknüpfen, ein Ansichtsmodell zu bilden. Wir dürfen keine unnötigen Daten an UI-Ebene passieren, während in Option B kann der Dienst mit Daten spielen und nur die benötigte / Minimum an den UI-Schicht nach der Kartierung (zum Ansichtsmodell) übergeben.

Auch hier lassen Sie uns mit der Option A gehen, setzte Ansichtsmodell in der UI-Ebene (und Entity-Modell in Service-Schicht).

Wenn die Service-Schicht Bedürfnisse der Ansichtsmodell abzubilden, dann die Service-Schicht Notwendigkeit, den Zugang Ansichtsmodell in UI-Ebene. Welche Bibliothek / Projekt? Das Ansichtsmodell sollte in einem separaten Projekt in der UI-Ebene sein, und dieses Projekt muss von Service Layer referenziert werden. Wenn das Ansichtsmodell nicht in einem separaten Projekt ist, dann gibt es zirkuläre Referenz, so dass keine gehen. Es sieht umständlich Dienstschicht Zugriff auf UI-Ebene haben, aber dennoch konnten wir damit fertig werden.

Aber was, wenn es eine andere UI-App diesen Service? Was, wenn es eine mobile App erhalten? Wie anders kann das Ansichtsmodell? Sollte der Dienst Zugriff auf das gleiche Ansicht Modellprojekt? Werden alle UI-Projekten Zugriff auf das gleiche Ansichtsmodell Projekt oder sie haben ihre eigenen?

Nach diesen Überlegungen meiner Antwort wäre, das Ansichtsmodell Projekt in Service Layer zu setzen. Jede UI-Ebene hat sowieso die Service-Schicht auf der Seite! Und es könnte viel ähnlicher sein Viewmodel, dass sie alle nutzen konnten (daher Mapping wird für Service-Layer einfacher). Mappings sind Linq diesen Tagen getan durch, das ist ein weiteres Plus.

Schließlich gibt es diese Diskussion über DTO. Und auch über Datenaufbelichtung in Viewmodels. Viewmodel mit Daten Anmerkungen (Microsoft.Web.Mvc.DataAnnotations.dll) nicht in Service-Schicht befinden, anstatt sie in UI-Ebene befindet (aber ComponentModel.DataAnnotations.dll kann in Dienstschicht befindet). Wenn alle Projekte in einer Lösung (SLN), dann spielt es keine Rolle, welche Ebene Sie es ausdrückte. In Unternehmensanwendungen, wird jede Schicht ihre eigene Lösung.

So DTO ist eigentlich ein Ansichtsmodell, weil meistens wird es eins zu eins Abbildung zwischen den beiden (etwa mit AutoMapper) sein. Wieder DTO hat immer noch die Logik für die Benutzeroberfläche benötigt (oder mehrere Anwendungen) und befindet sich in Service Layer. Und die UI-Ebene Ansichtsmodell (wenn wir Microsoft.Web.Mvc.DataAnnotations.dll verwenden) ist nur die Daten von DTO zu kopieren, mit einigen ‚Verhalten‘ / Attribute hinzugefügt werden.

[Jetzt dieser Diskussion geht es um eine interessante Wendung nehmen lesen Sie weiter ...: I]

Und glaube nicht, dass Daten-Annotation Attribute sind nur für UI. Wenn Sie die Validierung begrenzen mit System.ComponentModel.DataAnnotations.dll dann kann das gleiche Ansichtsmodell auch für Front-End und Back-End-Validierung (also UI-Wohnsitz-Ansichtsmodell-copy-of-DTO zu entfernen) verwendet werden. Außerdem Attribute können auch in Entity-Modellen verwendet werden. Zum Beispiel: mit .tt können Entity Framework-Datenmodelle mit Validierung werden automatisch generiert Attribute einige DB Validierungen wie Maximallänge zu tun, bevor mit dem hinteren Ende zu senden. Ein weiterer Vorteil ist, dass, wenn Back-End-Validierung in DB ändert sich dann .tt (liest DB Besonderheiten und erstellen Sie das Attribut für Entity-Klasse) automatisch, dass abholen. Dies kann UI-Validierung Unit-Tests zwingen auch zum Scheitern verurteilt, was ein großer plus (so wir es korrigieren können und informieren alle UIs / Verbraucher statt versehentlich vergessen und nicht an). Ja, die Diskussion bewegt sich in Richtung eines guten Rahmen-Design. Wie Sie können es sehen, ist alles im Zusammenhang. Tier-weise Validierung, Unit-Test-Strategie, Caching-Strategie, etc.

Obwohl nicht direkt mit dem questio bezogenn. 'Ansichtsmodell Fassade' in dieser erwähnt muss aufpassen Kanal 9 Link ist auch einen Besuch wert. Es beginnt genau bei 11 Minuten 49 Sekunden im Video. Da dies der nächste Schritt wäre, / dachte, sobald Ihre aktuelle Frage oben gegeben wird aussortiert: ‚Wie Viewmodel zu organisieren?‘

Auch in Ihrem Beispiel "_repository.ListContacts ()" ist ein Ansichtsmodell aus dem Repository zurück. Dies ist nicht eine reife Art und Weise. Repositorys sollten Unternehmen Modelle oder DB-Modelle bieten. Dies wird zu Ansicht Modellen umgewandelt und es ist diese Ansicht Modell, das von der Dienstschicht zurückgeführt wird.

Ich nehme an, das hängt davon ab, was man die „Dienste“ sein, in Betracht ziehen. Ich habe nie wirklich den Begriff mag Service im Zusammenhang mit einer einzigen Klasse; es ist unglaublich vage und hat man nicht viel sagen, über den eigentlichen Zweck der Klasse.

Wenn die „Service-Schicht“ ist eine physikalische Schicht, wie ein Web-Service, dann absolut nicht; Dienste in einer SOA-Kontext sollte Domäne / Geschäftsbetrieb, keine Daten und nicht die Präsentationslogik aus. Aber wenn Service ist nur als abstraktes Konzept für eine weitere Ebene der Verkapselung verwendet wird, ich sehe kein Problem mit ihm die Art und Weise verwenden Sie desribe.

Nur nicht Konzepte mischen. Wenn Ihre Service-Angebote mit Blick Modellen dann sollte es ein Präsentation Service und über die Spitze des geschichtet werden tatsächliche Modell, nie direkt auf die Datenbank oder jede Geschäftslogik zu berühren.

Diese kommen hat ein bisschen ein „es kommt“, wo ich arbeite - wir haben in der Regel einen Controller hatten einige Serviceaufwendig (en) - dann wieder die Kombination von DTO in ein ‚Viewmodel‘, die dann an den Client übergeben bekommen würden - entweder über JSON Ergebnis, oder in der Razor Vorlage gebunden.

Das Ding ist, etwa 80% der Zeit - die Abbildung von DTO zu Ansichtsmodell 1-1 war. Wir beginnen zu bewegen in Richtung ‚Wo nötig, nur um die DTO direkt verbrauchen, aber wenn der DTO und was wir in unserer Client / Ansicht müssen nicht zusammenpassen - dann schaffen wir ein Ansichtsmodell und machen die Zuordnung zwischen Objekten nach Bedarf‘.

Obwohl ich bin immer noch nicht davon überzeugt, dass dies die beste oder richtige Lösung - ‚? Sind wir einfach nur mit X auf den DTO die Bedürfnisse der Ansicht gerecht zu werden‘, wie es von einigen hitzigen Diskussionen führen endet

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top