Der Zweck eines Service Layer und ASP.NET MVC 2

Question

In dem Bemühen, zu verstehen MVC 2 und versuchen, meine Firma, um es als eine tragfähige Plattform für die zukünftige Entwicklung zu übernehmen, ich habe in letzter Zeit viel zu lesen getan. mit ASP.NET ziemlich ausschließlich für die letzten Jahre gearbeitet habe, hatte ich einig Nachholbedarf.

Zur Zeit verstehe ich die Repository-Muster, Modelle, Controller, Daten Anmerkungen, etc. Aber es gibt eine Sache, die mich von ganz Verständnis genug hält die Arbeit an einer Referenz-Anwendung zu starten.

Der erste ist der Service Layer-Muster. Ich habe viele Blog-Posts und Fragen hier auf Stack-Überlauf zu lesen, aber ich immer noch nicht ganz den Zweck dieses Musters verstehen. Ich beobachtete die gesamte Video-Serie auf MVCCentral auf dem Golf Tracker-Anwendung und auch in dem Demo-Code sehe er geschrieben, und es scheint mir, wie die Dienstschicht um das Repository-Muster nur einen weiteren Wrapper ist, der keine Arbeit überhaupt nicht durchführen.

Ich habe auch gelesen, diesen Beitrag: http: //www.asp. net / Lernen / Mvc / tutorial-38-cs.aspx und es schien, meine Frage zu beantworten etwas, aber wenn Sie mit Daten Anmerkungen sind Ihre Validierung durchgeführt werden, dies scheint nicht notwendig.

Ich habe für Demonstrationen sehe, Pfosten, etc., aber ich kann nicht scheinen, etwas zu finden, dass einfach das Muster erklärt und gibt mir zwingende Beweise dafür, es zu benutzen.

Kann jemand bitte geben Sie mir eine 2. Klasse (ok, vielleicht 5. Klasse) Grund, dieses Muster zu verwenden, was ich verlieren würde, wenn ich es nicht tun, und was ich gewinnen, wenn ich tun?

Answer 1

In einem MVC-Muster, das Sie Verantwortlichkeit haben getrennt zwischen den drei Spielern. Model, View und Controller

Das Modell, das Geschäft Zeug dafür verantwortlich ist, stellt die Ansicht, die Ergebnisse des Unternehmens (sofern auch die Eingabe für das Geschäft von dem Benutzer), während der Controller verhält sich wie der Kleber zwischen dem Modell und der Ansicht, das Innenleben zu trennen jeder von dem anderen.

Das Modell ist in der Regel durch eine Datenbank gesichert, so dass Sie einige DAOs Zugriff auf das haben. Ihr Unternehmen hat einige ... na ja ... Geschäft und speichert oder abruft Daten in / aus der Datenbank.

Aber wer koordiniert die DAOs? Der Controller? Nein! Das Modell sollte.

Geben Sie die Service-Schicht. Die Service-Schicht hohen Service an den Controller zur Verfügung stellen und andere verwalten (untere Ebene) Spieler (DAOs, sonstige Dienstleistungen usw.) hinter den Kulissen. Es enthält die Business-Logik Ihrer Anwendung.

Was passiert, wenn Sie es nicht benutzen?

In Kürze erhalten Sie haben die Business-Logik irgendwo zu setzen und das Opfer ist in der Regel die Steuerung.

Wenn der Controller Web-centric muss es seinen Eingang empfangen und Antwort als HTTP-Anfragen, Antworten. Aber was, wenn ich möchte, dass mein App nennen (und erhalten Sie Zugriff auf das Geschäft es bietet) aus einer Windows-Anwendung, die mit RPC oder einer anderen Sache in Verbindung steht? Was dann?

Nun, müssen Sie den Controller neu zu schreiben und die Logik Client Agnostiker zu machen. Aber mit der Service-Schicht haben Sie bereits. Yyou brauchen nicht die Dinge neu zu schreiben.

Der Service-Layer ermöglicht die Kommunikation mit DTOs, die zu einer bestimmten Controller-Implementierung nicht gebunden sind. Wenn der Controller (egal, welche Art von Controller) die entsprechenden Daten zur Verfügung stellt (keine mater die Quelle), um Ihren Service-Layer wird seine Sache tut einen Dienst an den Anrufer bereitstellt und die Anrufer aus allen Aufgaben der Business-Logik versteckt beteiligt.

Answer 2

Ich muss sagen, dass ich mit dpb mit dem oben zustimmen, der Wrapper dh Service Layer ist wiederverwendbar, mockable, ich bin derzeit in den Prozess der Aufnahme dieser Schicht in meinem app ... hier sind einige der Fragen / Anforderungen I am grübeln über (sehr schnell: p), die Hilfe zu youeself aus sein könnte ...
1. Mehrere Portale (z Bloggers Portal, Kundenportal, internes Portal), die von vielen verschiedenen Benutzern zugegriffen wird benötigt, um werden. Sie alle müssen getrennte ASP.NET MVC-Anwendungen sein (eine wichtige Voraussetzung)
2. Innerhalb der Anwendungen selbst einige Anrufe auf die Datenbank wird ähnlich sein, die Methoden und die Art und Weise werden die Daten aus der Repository-Schicht behandelt. Ohne Zweifel einige Controller von jedem Modul / portal machen genau oder eine überladene Version des gleichen Anrufs, damit eine mögliche Notwendigkeit für eine Dienstschicht (Code-Schnittstellen), die ich dann in einer separaten Klasse-Projekt kompilieren.
3. Wenn ich ein separates Klasse-Projekt für meine Service-Layer erstelle Ich brauche das gleiche für die Data Layer oder kombinieren Sie es mit dem Service Layer zu tun und entfernt das Modell hält aus dem Web-Projekt selbst. Zumindest diese Art und Weise, wie mein Projekt wächst ich die Datenzugriffsschicht werfen kann (d LinqToSql -> NHibernate) oder ein Teammitglied kann, ohne in einem anderen Projekt auf einem beliebigen Code zu arbeiten. Der Nachteil könnte sein, sie blasen konnte alles lol ...