Nehmen wir an, ich habe ein folgendes Repomuster:
%Vor%dann in meinem Controller:
%Vor%Grundsätzlich ist mein Muster etwas wie
View <-> Controller -> Repo -> EF -> SQL Server
aber ich habe viele Leute gesehen, die das gemacht haben
View <-> Controller -> Service -> Repo -> EF -> SQL Server
Meine Frage ist also:
Warum und wann brauche ich service layer ? Fügen Sie nicht einfach einen weiteren unnötigen Layer hinzu, weil jede nicht-generische Methode bereits in ICustRepo ?
Sollte die Serviceebene DTO oder my ViewModel zurückgeben?
Sollte die Serviceebene 1: 1 mit meinem Repo abbilden?
Ich habe mich ein paar Tage umgesehen, aber ich bin nicht mit den Antworten zufrieden.
Jede Hilfe wird geschätzt und entschuldigt sich für schlechtes Englisch.
Danke.
UPDATE:
Unterschied zwischen Repository und Service-Layer?
Ich habe das schon gelesen. Ich kenne den Unterschied zwischen diesen beiden schon, aber ich möchte wissen warum und warum. Also das beantwortet meine Frage nicht
TL; DR
Erläuterung
Die typische 3-Schichten-Architektur besteht aus Präsentationsschicht, Service / Domänenschicht, Datenzugriffsebene (DAL).
Stellen Sie sich die Service-Schicht als "Kern" Ihrer Anwendung vor. Tipisch hat Service Layer nur Repository-Schnittstellen, die in der DAL implementiert werden.
Dadurch können Sie "einfach" den Zugriff auf Daten ändern. Die von der Service-Schicht zurückgegebenen Objekte sollten keine DAO-Objekte sein, da die Präsentations-Ebene nicht einmal "weiß", dass die DAL existiert.
Szenario: Sie haben eine 3-stufige Lösung. Derzeit macht es nicht viel Sinn, alle Ebenen zu haben.
%Vor%Jetzt möchten Sie eine REST API in ASP.NET MVC WebApi haben
%Vor%Nun möchten Sie beispielsweise Entity Framework nicht mehr als Datenzugriff verwenden und NHibernate verwenden.
%Vor%Beachten Sie, dass wir eine neue Form der Präsentation hinzugefügt haben und die Art, wie wir auf Daten zugreifen, geändert haben, aber die Service-Schicht hat sich nie geändert.
Tipischerweise stellt Service Layer Schnittstellen bereit, die in der Datenzugriffsebene implementiert werden, damit wir die gewünschte "Abstraktion" erhalten.
Ich habe ein Projekt mit dieser Architektur in der Universität realisiert. Sie können den Code HIER
sehenIch hoffe, das hat geholfen. Tut mir leid, wenn ich so langweilig bin @ erklären Dinge: P
Ad.1 Service-Schicht sollte Platz für die gesamte Geschäftslogik sein. Es geht mehr um getrennte Verantwortlichkeiten:
Controller - verantwortlich für die Vorbereitung von viewModel und Übergabe an die spezifische Ansicht,
Repository - abstrakte Ebene, die für das Sammeln von Entitäten aus der Datenbank verantwortlich ist
Service - verantwortlich für komplexe Logik. Es gibt oft Fälle, in denen der Dienst viele Entitäten verwendet, um Logik zu erzeugen und nur DTO zurückzugeben.
Ad.2 Meiner Meinung nach sollte Service-Layer DTO-Objekte zurückgeben, die den View-Modellen in Controllern zugeordnet werden sollten.
Ad.3 Nein, das ist nicht der Fall. In Ihrem Beispiel können Sie GetBadCust und GetGoodCust von Repo in den Service verschieben und einige DTO zurückgeben
Tags und Links asp.net-mvc c# entity-framework design-patterns repository