Der Zweck einer Service-Schicht und ASP.NET MVC 2

Question

In dem Bemühen, MVC 2 zu verstehen und zu versuchen, meine Firma als eine praktikable Plattform für die zukünftige Entwicklung zu übernehmen, habe ich in letzter Zeit eine Menge gelesen. Nachdem ich in den letzten Jahren ziemlich exklusiv mit ASP.NET gearbeitet habe, musste ich etwas nachholen.

Momentan verstehe ich die Repository-Muster, Modelle, Controller, Datenanmerkungen usw. Aber es gibt eine Sache, die mich davon abhält, genug zu verstehen, um mit der Arbeit an einer Referenzanwendung zu beginnen.

Das erste ist das Service Layer Pattern. Ich habe viele Blogposts und Fragen hier auf Stack Overflow gelesen, aber ich verstehe den Zweck dieses Musters immer noch nicht vollständig. Ich habe mir die gesamte Videoserie bei MVCCentral in der Golf Tracker-Anwendung angeschaut und auch den Demo-Code angeschaut, den er gepostet hat, und es sieht für mich so aus, als wäre die Service-Schicht nur ein weiterer Wrapper um das Repository-Muster, das überhaupt keine Arbeit leistet.

Ich las auch diesen Beitrag: http://www.asp.net/Learn/mvc/tutorial-38-cs.aspx und es schien etwas meine Frage zu beantworten, jedoch, wenn Sie Datenanmerkungen verwenden, um Ihre Validierung durchzuführen, scheint dies unnötig.

Ich habe nach Demonstrationen, Posts usw. gesucht, aber ich kann nichts finden, was nur das Muster erklärt und mir überzeugende Beweise gibt, es zu benutzen.

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

Answer 1

In einem MVC-Muster haben Sie Aufgaben getrennt zwischen den 3 Spielern: Model, View und Controller.

Das Modell ist verantwortlich für die geschäftlichen Dinge zu tun, die Ansicht präsentiert die Ergebnisse des Geschäfts (Bereitstellung von Input für das Geschäft von dem Benutzer), während der Controller wie der Klebstoff zwischen dem Modell und der Ansicht wirkt Funktionieren von jedem von den anderen.

Das Modell wird normalerweise von einer Datenbank gesichert, sodass einige DAOs darauf zugreifen können. Ihr Geschäft macht einige ... gut ... Geschäfte und speichert oder ruft Daten in/aus der Datenbank ab.

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

Geben Sie die Service-Schicht ein. Die Service-Schicht bietet dem Controller einen hohen Service und verwaltet andere (untergeordnete) Player (DAOs, andere Dienste usw.) hinter den Kulissen. Es enthält die Geschäftslogik Ihrer App.

Was passiert, wenn Sie es nicht verwenden?

Sie müssen die Geschäftslogik irgendwo und das Opfer ist in der Regel der Controller.

Wenn der Controller webzentriert ist, muss er seine Eingaben erhalten und als HTTP-Anfragen antworten. Aber was, wenn ich meine App (und Zugang zu dem Geschäft, das sie bereitstellt) von einer Windows-Anwendung aufrufen möchte, die mit RPC oder etwas anderem kommuniziert? Was dann?

Nun, Sie müssen den Controller neu schreiben und den Logik-Client agnostisch machen. Aber mit der Service-Schicht haben Sie das schon. Sie müssen die Dinge nicht neu schreiben.

Die Service-Schicht ermöglicht die Kommunikation mit DTOs, die nicht an eine bestimmte Controller-Implementierung gebunden sind.Wenn der Controller (unabhängig von der Art des Controllers) die entsprechenden Daten zur Verfügung stellt (nicht die Quelle), wird Ihre Serviceebene ihre Aufgabe erfüllen und dem Anrufer einen Service bieten, der den Anrufer von allen Verantwortlichkeiten der beteiligten Geschäftslogik fernhält.

Answer 2

Ich muss sagen, ich stimme dpb mit dem oben genannten, der Wrapper dh Service Layer ist wiederverwendbar, mockbar, ich bin derzeit dabei, diese Schicht in meiner App zu integrieren ... hier sind einige der Probleme/Anforderungen Ich überlege (sehr schnell: p), dass könnte Hilfe zu sich selbst sein ...
1. Mehrere Portale (zB Bloggers Portal, Client-Portal, internes Portal), die benötigt werden, um von vielen verschiedenen Benutzern zugegriffen werden. Sie müssen alle separate ASP.NET MVC-Anwendungen sein (eine wichtige Voraussetzung).
2. Innerhalb der apps selbst einige Aufrufe an die Datenbank werden ähnlich sein, die Methoden und die Art, wie die Daten von der Repository-Schicht behandelt wird. Ohne Zweifel werden einige Controller von jedem Modul/Portal genau dieselbe oder eine überladene Version des gleichen Aufrufs machen, daher ein möglicher Bedarf für eine Dienstschicht (Code zu Schnittstellen), die ich dann in einem separaten Klassenprojekt kompilieren werde.
3. Wenn ich ein separates Klassenprojekt für meine Service-Schicht erstelle, muss ich möglicherweise dasselbe für die Datenschicht tun oder sie mit der Service-Schicht kombinieren und das Modell vom Web-Projekt selbst fernhalten. Mindestens so, wie mein Projekt wächst, kann ich die Datenzugriffsebene (d. H. LinqToSql -> NHibernate) auswerfen, oder ein Teammitglied kann ohne irgendeinen Code in irgendeinem anderen Projekt arbeiten. Der Nachteil könnte sein, dass sie alles in die Luft sprengen könnten ...