Mit Layered Architekturen in ASP.NET

Ein Ansatz zur Gestaltung von Web-Anwendungen zu konzentrieren sich auf klar definierte Schichten der Architektur der Anwendung. Dieser Ansatz ist ähnlich wie ein Architekt ein Gebäude entwirft. Wenn Sie jemals detaillierte Baupläne für einen Wolkenkratzer gesehen haben, wissen Sie die Baupläne getrennte Pläne für die Stiftung gehören, Rahmen, Dach, Sanitär-, Elektro-, und anderen Etagen des Gebäudes.

Mit einer geschichteten Architektur können Spezialisten entwerfen und zu entwickeln, die "Etagen" - genannt Lagen - unabhängig vorgesehen, dass die Verbindungen zwischen den Schichten (die Schnittstellen) Sind sorgfältig durchdacht.

Die Schichten sollten so weit wie möglich voneinander unabhängig sein. Unter anderem bedeutet, dass ein paar Must-dos und sollst Nichtse beachtend:

• Jede Schicht muss einen klar definierten Fokus haben. Um die Ebenen zu entwerfen richtig, müssen Sie klar die Aufgaben und Verantwortlichkeiten der einzelnen Schicht buchstabieren.
• Die Schichten sollten ihre eigenen Angelegenheiten kümmern. Wenn eine Schicht für die Interaktion mit dem Benutzer zuständig ist, wird nur dieser Schicht erlaubt, mit dem Benutzer zu kommunizieren. Andere Schichten, die Informationen vom Benutzer erhalten müssen, müssen dies über das User Interface Layer.
• Klar definierte Protokolle müssen sich für die Schichten miteinander zu interagieren, eingestellt werden. Die Interaktion zwischen den Schichten erfolgt nur durch diese Protokolle.

Beachten Sie, dass die Schichten nicht direkt auf eine bestimmte Anwendung gebunden. Zum Beispiel könnte eine Architektur für ein Online-Bestellsystem und für ein Online-Forum gleich gut funktionieren. Als Ergebnis hat geschichtete Architektur nichts mit dem ERDs zu tun, die eine Datenbank oder die Datenflussdiagramme definieren, die definieren, wie die Daten in der Anwendung fließt. Es ist eine separate Struktur.

Wie viele Schichten?

Es gibt verschiedene Ansätze zur Anwendungsarchitektur, die von der Anzahl der Schichten variieren. Ein gemeinsames System ist die Anwendung in zwei Schichten zu brechen:

• Anwendungsschicht: Das Design der Benutzeroberfläche und die Umsetzung der Geschäftspolitik sind in dieser Schicht behandelt. Diese Schicht kann auch handhaben Transaktionslogik - der Code, der Gruppen-Datenbank-Updates in Transaktionen und stellt sicher, dass alle Updates innerhalb einer Transaktion konsequent vorgenommen werden.
• Data Access Layer: Die zugrunde liegende Datenbank-Engine, die die Anwendung unterstützt. Diese Schicht ist verantwortlich für die Integrität der Datenbank aufrechterhalten wird. Einige oder alle der Transaktionslogik kann in dieser Schicht durchgeführt werden.

Im Zweischichtmodell ist die Anwendungsschicht die ASP.NET-Seiten, die die Seiten definieren, um den Benutzer sowie die Code-Behind-Dateien präsentiert, die die Anwendungslogik implementieren. Die Data Access Layer ist der Datenbankserver, der die Datenbank wie Microsoft SQL Server oder Oracle verwaltet.

Beachten Sie, dass ASP.NET 2.0 nicht, dass Sie die Anwendung des Logik-Code in einem separaten Code-Behind-Datei platzieren erfordert. Stattdessen können Sie die Logik-Code mit der Präsentation Code in der gleichen Datei intersperse. Allerdings ist es fast immer eine gute Idee, separaten Code-Behind-Dateien verwenden, um die Anwendungslogik von der Präsentation Code zu trennen. Alle in diesem Buch vorgestellten Anwendungen separaten Code-Behind-Dateien verwenden.

Die Trennung zwischen der Anwendung und Datenzugriffsschichten ist nicht immer so eindeutig, wie es sein könnte. Aus Performance-Gründen wird Transaktionslogik oft auf dem Datenbank-Server (in Form von gespeicherten Prozeduren) verschoben und Geschäftsregeln werden auf dem Datenbankserver mit Einschränkungen und Trigger häufig umgesetzt. So übernimmt der Datenbankserver oft einige der Anwendungslogik.

Wenn diese Unübersichtlichkeit Sie stört, können Sie ein verwenden Drei-Schicht-Architektur, die fügt eine zusätzliche Schicht von Geschäftsregeln und Richtlinien zu behandeln:

• Presentation Layer: Diese Schicht übernimmt die Benutzeroberfläche.
• Business Rules Schicht: Diese Schicht übernimmt die Geschäftsregeln und Richtlinien der Anwendung. Zum Beispiel, wenn eine Verkaufsanwendung Rabatte für bestimmte Benutzer gewährt wird die Rabattpolitik in dieser Schicht realisiert.
• Data Access Layer: Die zugrunde liegende Datenbankmodell, das die Anwendung unterstützt.

eine separate Schicht für Geschäftsregeln erstellen, können Sie die Regeln aus der Datenbank-Design und die Präsentationslogik zu trennen. Geschäftsregeln sind Änderungen vorbehalten. Indem man sie in einer separaten Ebene platzieren, haben Sie eine einfachere Aufgabe, sie zu ändern später, als wenn sie in der Benutzeroberfläche oder Datenbank-Design integriert sind.

Model-View-Controller-

Ein weiteres gemeinsames Modell für die Gestaltung von Web-Anwendungen aufgerufen Model-View-Controller- (MVC). In dieser Architektur wird die Anwendung in drei Teile zerbrochen:

• Modell: Das Modell- der Business-Schicht der Anwendung ist in der Tat. Es besteht in der Regel von Objekten, die die Geschäftseinheiten darstellen, die die Anwendung, wie Kunden und Produkte bilden.
• Aussicht: Das Aussicht ist die Benutzeroberfläche der Anwendung. In einer Web-Anwendung, besteht diese aus einem oder mehreren HTML-Seiten, die das Look and Feel der Anwendung definieren.
• Regler: Das Regler verwaltet die von der Anwendung verarbeiteten Ereignisse. Die Ereignisse werden in der Regel von User-Interface-Aktionen, wie der Benutzer auf eine Schaltfläche oder Auswahl eines Elements aus einer Dropdown-Liste klicken.

In einer typischen ASP.NET-Anwendung implementiert die ASPX-Datei die View- das Modell und Controller-Funktionen kombiniert werden und durch die Code-Behind-Datei behandelt. Somit kann der Code-Behind-Datei als die gedacht werden, Modell-Controller.

Sie können natürlich, trennen Sie die Modell- und Controller-Funktionen durch separate Klassen für die Geschäftseinheiten zu schaffen. Der Einfachheit halber halten die Anwendungen in diesem Buch das Modell und Controller-Funktionen kombiniert in der Code-Behind-Datei.