« »

Architekturprinzip Separation of Concerns

26. Februar 2009 Roland

Dieser Artikel ist Teil 15 von 26 der Artikelserie Programmieren

Programmieren

Normalerweise ist es nicht sinnvoll, alle Funktionalitäten in einer Datei unterzubringen.
Häufig wird leider alles in eine Datei reingefummelt. Es gibt hunderte von schlechten Beispielen bei denen in einer Datei folgende Sprachelemente vorhanden sind:

HTML
In einer Datei findet sich HTML Tags. Diese beinhalten die Dokumentenstruktur die auf den Webclient dargestellt werden soll.
CSS
Das Cascating Stylesheet wird nicht in einer eigenen Datei ausgelagert sondern per inline Definition in das HTML Dokument mit eingebunden.
JavaScript
Die Funktionen werden nicht in eine Datei ausgelagert sondern gerade auch noch reingefummelt. Damit hat man schon ziemlich viel verschiedenes Sprachgewirr beisammen. Aber damit sind nur die auf dem Webclient zu interpretierenden Sprachelemente hinterlegt. Jetzt kommen noch die Serverbasierten Sprachelemente hinzu.
PHP
Viele bauen ihre PHP Dokumente und fummeln da gleich alles was es auf dem Client zu tun gibt mit rein. Das Dokument ist wirklich weltklasse zu lesen! Das ist so ähnlich, wie wenn du in einem Dokument Englisch, Deutsch, Spanisch und Russisch miteinander kreuzt. Aber damit nicht genug. Es geht noch besser…
SQL
Ja, auch noch komplexe Datenbankabfragen müssen unbedingt mit in das Dokument rein. Und dann haben wir viel beieinander und fühlen uns irgendwie wie beim Turmbau zu Babel…

Warum ist dass nicht gut?

Wenn man mal anschaut wo welche Programmiersprachen ausgeführt und interpretiert werden, ist es sinnvoll auch die Dateien entsprechend anzuordnen. Wieso soll sich ein Server mit JavaScript rumschlagen? Warum soll die Darstellung auf dem Server interpretiert werden?
Eben, dass soll nicht auf dem Webserver passieren.
Eine gute Architektur sorgt dafür, dass alle verschiedenen Sprachelemente und Komponenten dort installiert und ausgeführt werden wo sie wirklich gebraucht werden. Weiterhin kann man sehr gut die einzelnen Sprachen in verschiedene Dateien auslagern und somit eine gut zu testende Applikation erstellen.
Denk immer dran. Deine Applikation wird einen Fehler haben und du musst diesen Fehler in einem halben Jahr finden. Dann bist du froh, wenn du deine Programmteile sinnvoll geordnet hast.

Was bedeutet jetzt Seperations of Concern?

Wir werden die Webapplikationen immer so gestalten, dass die Aktivitäten an den Orten ausgeführt werden, wo sie wirklich notwendig sind.
Folgende Aktivitäten werden normalerweise benötigt:

Präsentation
Auf dem Webbrowser muss von unserer Webapplikation die Ein- und Ausgabeelemente dargestellt werden. Ein Anwender möchte ein Textfeld vorfinden um seinen Namen einzutragen. Also wird HTML und CSS auf dem Webbrowser dargestellt und hierfür auch bereit gestellt.
Präsentations Controller
Der Präsentations Controller einer Webapplikation steuert die Programmabläufe bei der Eingabe. Er kümmert sich um einfache Typüberprüfungen, also ob ein String auch wirklich Text beinhaltet und ob eine Zahl als Zahl und nicht als String eingegeben wurde. Weiterhin können einfache Algorithmen, wie Beispielsweise die Suche nach einer Auswahl von Städten, in diesem Controller abgehandelt werden. Dieser Controller sorgt dafür, dass die Webapplikation für den Anwender schnell und einfach zu bedienen ist. Somit wird der Code sehr nah beim Anwender benötigt und wir liefern diesen Code an den Webclient aus. Der Webclient interpretiert diesen Code.
Business Logic Controller
Hierbei handelt es sich um die Abläufe die benötigt werden um die Daten aus dem Web zu speichern und zu verändern. Bei einer Autovermietung wird die Businesslogik benötigt um die einzelnen Autos an die Kunden übergeben zu können. Diese Logik ist dort wo die Daten sind, also auf dem Webserver.
Modelle
Die Daten werden in Datenbanken oder in anderen Datenstrukturen auf dem Server abgespeichert. Modelle verwalten einzelne Datensätze und helfen die Daten konsistent halten. Die Logik für die Modelle wird auf dem Webserver, die Daten selbst jedoch meistens im Datenbankserver gehalten.
Persistence Model
Auf dem Datenbankserver werden die Modelle persistent gespeichert. Um diese Speicherung beschreiben zu können, werden die Persistenzmodelle von den logischen Modellen getrennt. So können Modelle für Datenbanken oder für Fileserver erstellt werden.
SQL und SQL Prepared Statemenents
Die SQL Sprachelemente werden normalerweise auf dem Webserver installiert. Es gibt jedoch auch optimierte SQL Statements die direkt auf dem SQL Server installiert werden. Diese werden vorübersetzt und können schneller ausgeführt werden.

In der folgenden Grafik habe ich die auf der linken Seite die Sprachen und auf der rechten Seite Architekturelemente abgebildet. Dieses Deployment Diagramm soll zeigen auf welcher Komponente die jeweiligen Elemente ausgeführt werden.
Komponenten und die ausführbaren Elemente

Merken und weiterempfehlen Diese Icons verlinken auf Bookmark Dienste bei denen Nutzer neue Inhalte finden und mit anderen teilen können.
  • Technorati
  • Wikio DE
  • Webnews
  • MisterWong
  • Y!GG
  • Digg
  • del.icio.us

Der Beitrag wurde am Donnerstag, den 26. Februar 2009 um 00:28 Uhr veröffentlicht und wurde unter Programmieren abgelegt.
Kurzlink: http://www.baldenhofer.eu/blog/?p=233

Dir gefiel der Artikel? Dann abonniere doch den RSS Feedrss

Du kannst die Kommentare zu diesem Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Eine Reaktion zu “Architekturprinzip Separation of Concerns”

  1. Roland sagt:
    1. März 2009 um 10:04

    Ich habe den Artikel ein wenig überarbeitet und das Mischmasch aus Sprachen und Architekturelementen beseitigt.

Schreibe mir

zum Seitenanfang