Unterschied zwischen 3-Tier-Architektur und MVC (Model, View Controller) in ASP.Net

Ich würde gerne wissen, wie sich die 3-Tier-Architektur von MVC (Model, View Controller) in ASP.Net unterscheidet, da mir scheint, dass dieselbe Architektur gilt.

In 3-Tiere haben wir User Services Layer, BusinessLayerund DataAccessLayer, auf der anderen Seite haben wir Model, Viewund Controller. Dies scheint mir dieselbe Architektur zu sein.

Kann jemand erklären, ob sich die beiden Architekturen wirklich unterscheiden und wie sich die einzelnen Schichten voneinander unterscheiden?

Dies ist wie die Frage, was der Unterschied zwischen einem Apfel und einem Apfelkern ist. Diese beiden Architekturen ersetzen sich nicht gegenseitig. Ich denke , eine genauere Ansicht ist , dass die 3-Tier - Architektur erweitert MVC.

Die MVC-Architektur

• Modelle: Diese repräsentieren "Zeug" in Ihrer Anwendung. Diese Schicht ist in den letzten Jahren etwas verschwommen, wie ich später erklären werde.

• Ansichten: Die Benutzeroberfläche. Die Sache, mit der der Benutzer interagiert.

• Controller: Der Programmiercode, der auf den Benutzer und auf Änderungen in der Modellebene reagiert

Die 3-Tier-Architektur

Mit der dreistufigen Architektur haben Sie Ebenen mit unterschiedlichen Verantwortlichkeiten.

• Benutzerdienste: (oder "Dienste" im Allgemeinen) In dieser Ebene geht es mehr darum, das Abrufen und Ändern der Ebene "Modell" zu koordinieren. Hier werden komplexe, mehrstufige Aktionen ausgeführt

• Business Layer: Dies sind die Geschäftsregeln, die in den Programmcode eingraviert sind. Was "The Business" will, wird in dieser Ebene durchgesetzt.

• Datenzugriffsschicht: Eine oder mehrere Klassen, die für den Zugriff auf einen persistenten Datenspeicher verantwortlich sind.

Der einzige Teil der dreistufigen Architektur, der sich mit MVC überschneidet, ist die "Business Layer". Die "Modelle" in MVC und die "Business Layer" in 3-Tier-Architektur versuchen, dasselbe Ziel zu erreichen.

Das "M" in MVC ist verschwommen

Die "Modell" -Schicht in MVC wurde in den letzten Jahren erweitert. Nach dem, was ich gesehen habe, gibt es zwei, möglicherweise drei Arten von Modellen:

1. Domain-Modelle: Diese repräsentieren die "Dinge", die "The Business" interessieren - die Business Domain. Diese Klassen enthalten Daten und alle Prozeduren, die mit diesen Daten arbeiten, um Geschäftsregeln durchzusetzen. Häufig sind Domänenmodelle an Tabellen in einer Datenbank gebunden. Dies scheint zur "Business Layer" der 3-Tier-Architektur zu passen.

2. Ansichtsmodelle: Dies sind Klassen, mit denen die Daten aus den Domänenmodellen in etwas umgewandelt werden, das für die Ansicht schmackhafter ist. Dies passt nirgendwo in die 3-Tier-Architektur, da Ansichtsmodelle weder Geschäftslogik implementieren noch irgendeine Art von Service oder Datenzugriff bieten.

3. Geschäftsmodelle: In komplexen Anwendungen besteht die Notwendigkeit, das Domänenmodell von der Geschäftslogik zu entkoppeln. Die Geschäftsmodelle enthalten Daten und Prozeduren, die mit diesen Daten arbeiten, um Geschäftsregeln zu implementieren, und die Domänenmodelle werden in "Property Bags" verwiesen - Objekte, die nur Daten enthalten, aber kein Verhalten enthalten. Domänenmodelle werden zu einer anderen Form des Datenübertragungsobjekts zwischen der Datenbank und der Anwendung.

Nirgendwo in MVC wird der Datenzugriff erwähnt. In einigen Fällen werden Sie feststellen, dass der Datenzugriff zur "Modell" -Ebene von MVC gehört, die, wie wir gesehen haben, keine eindeutige Ebene mehr ist. Ich sehe wirklich , dass eine dreistufige Architektur mit MVC gepaart wird , um eine ganze Anwendung zu erstellen. Das eine erweitert oder verbessert das andere:

• Modelle
  • Domänenmodelle (MVC / 3-Tier)
  • Modelle anzeigen (MVC)
  • (optional) Geschäftsmodelle (MVC / 3-Tier)
• Ansichten (MVC)
• Controller (MVC)
• Datenzugriff (3-Tier)
• Dienstleistungen (3-Tier)

Es gibt einige Schnittpunkte, die jedoch weitgehend voneinander getrennt sind und zusammen zum Entkoppeln und Isolieren verschiedener Komponenten eines größeren Systems verwendet werden.

Nein, sie sind nicht gleich.

MVC ist ein Entwurfsmuster zum Strukturieren von Benutzeroberflächencode. Es könnte in einer dreistufigen Architektur verwendet werden. In diesem Fall würde das Muster in die Schicht der Benutzerdienste gehören. Es kann aber auch für die Benutzeroberfläche in Anwendungen verwendet werden, die nicht dreistufig sind - z. B. ein Taschenrechner ohne zugrunde liegende Persistenz und daher ohne Datenzugriffsschicht.

In einer dreistufigen Architektur mit einem MVC-Frontend wären die als Modell verwendeten Domänenobjekte die Objekte aus der Geschäftsschicht, aber das MVC-Muster gibt nicht wirklich an, um welche Art von Objekten es sich bei dem Modell handelt, sondern nur um ihre Rolle im Muster ist. In der MVVM-Variante sind die Modelle beispielsweise UI-spezifische Adapter über den Domänenobjekten. In diesem Fall gehört sogar das Modell in die Benutzerdienstschicht.

Ich weiß, dass es unzählige verschiedene Antworten geben wird, aber ich werde Ihnen meine Meinung dazu geben.

Es ist die bekannteste Antwort in der Softwareentwicklung "Es kommt darauf an".

Im Wesentlichen handelt es sich neben verschiedenen Implementierungs- und theoretischen Unterschieden um sehr ähnliche Muster mit ähnlichen Abläufen.

Wo es darauf ankommt, ist die Anwendung, die Sie erstellen. Eine einfache Webanwendung verfügt möglicherweise nur über eine MVC-Schicht, die über ein ORM mit der Datenbank kommuniziert. Bei einer komplexeren kann MVC das Front-End in der Benutzerebene verwalten, wobei komplexere, nicht vom Benutzer exponierte Operationen in der BL-Schicht stattfinden, wobei die Datenschicht aus mehreren Quellen besteht.