Entwicklung eines Event-Managers mit ASP.NET 1.1

Geschrieben von: Alexander Zeitler
Kategorie: ASP.NET

Die Zahl der Informations- und Fortbildungsveranstaltungen - inbesondere im IT-Sektor - nimmt zu. Die Besucher dieser Veranstaltungen erwarten heutzutage, daß Sie sich über eine Website komfortabel anmelden können und auch weitergehende Informationen zum Event erhalten. Dieser Artikel gibt einen Überblick über die Architektur des EventManagers, der für die vom 04. - 05. Juni 2004 zum ersten Mal stattfindende .NET Community Conference mit ASP.NET 1.1 und C# entwickelt wurde.

Zielsetzung

Wie bereits erwähnt, soll die Applikation den Interessenten die Möglichkeit bieten, sich sowohl auf einer öffentlichen Website über bevorstehende als auch über bereits vergangene Events zu informieren.

Nach der Registrierung kann der Besucher auf einer per Login geschützten, privaten Seite (Bild) sein Profil (Bild), sein Paßwort (Bild) und seine Event-Anmeldungen (Bild) verwalten.

• Private Seite
  
• Profil
  
• Paßwortwartung
  
• Event-Anmeldungen
  

Verwaltet wird die Applikation rollenbasiert von einem Enterprise Administrator sowie beliebig vielen Event Administratoren und Event Managern.

Hiermit ergibt sich also folgendes Schema der Applikation:

Architektur der Applikation

Um eine flexible Anpassung der Applikation hinsichtlich beliebiger Frontends (Web, Windows, etc.) und Datenbanken (Access, SQL Server, etc.) zu ermöglichen, wird die Applikation mehrschichtig aufgebaut:

Wie man sieht ist die Applikation als typische 3-Schichten (Three Tier)-Applikation ausgeführt und in die Bereiche Präsentationsschicht (Presentation Layer), Geschäftslogik (Business Logic Layer) und Datenbankzugriffsschicht (Data Access Layer) unterteilt.

Die Datenspeicherung erfolgt wie gefordert in der Datenbank.

Die drei genannten Layer, die das Event-Management abbilden, kommunizieren auf allen Ebenen miteinander und werden durch ein umfassendes Sicherheitskonzept gegen eine Vielzahl von Angriffen geschützt.

Data Access Layer

Die Aufgaben des Data Access Layers bzw. dessen Klassen und Methoden (Data Access Components, kurz DAC) bestehen darin, Daten aus der Datenbank zu lesen bzw. die Daten der Geschäftsobjekte (Business Entities, kurz BE) aus dem Business Logic Layer in der Datenbank zu speichern. Hierbei implementieren die DAC's auch Geschäftslogik, um datenbankbezogene Aufgaben zu erledigen.

Der Data Access Layer stellt Methoden bereit, um die folgenden Aufgaben, die er vom Business Logic Layer gestellt bekommt, zu erledigen:

• Erzeugen von neuen Einträgen in der Datenbank (Create) anhand übergebener Daten aus dem Business Logic Layer
• Lesen von Applikationsdaten aus der Datenbank und Weitergabe an den Business Logic Layer (Read)
• Aktualisieren von Applikationsdaten aufgrund von Änderungen an den Daten durch den Business Logic Layer (Update)
• Löschen von Daten in der Datenbank (Delete)

Diese vier Vorgänge werden häufig mit dem Begriff "CRUD" abgekürzt, abgeleitet von den Anfangsbuchstaben der englischen Begriffe.

Außerdem implementiert der Data Access Layer, wie bereits erwähnt, auch Geschäftslogik und zwar in der Art, daß er eine Methode bereitstellt, welche beispielsweise alle Anmeldungen zu einem Event auflistet.

Typischerweise implementiert jede DAC die Methoden für jeweils eine Datenbank und kapselt diese für bestimmte Tabellen. So wären z.B. eine Klasse und deren Methoden für die Bearbeitung der Event-Tabelle zuständig, eine andere Klasse für die Besucher- und Adress-Tabellen.

Zur Vereinfachung häufig wiederkehrender Aufgaben wie das Lesen und Schreiben von Daten stellt Microsoft den Data Access Application Block (DAAB) bereit. Dieser bietet optimierte Methoden für den Zugriff auf SQL Server und Access-Datenbanken mittels gespeicherten Prozeduren bzw. parametrisierten Abfragen sowie SQL-Abfragen. Der DAAB liefert SqlDataReader-, DataSet- und XmlReader-Objekte als Abfrageergebnisse zurück. Für die Zusammenarbeit mit Typed DataSets liefert er ebenfalls passende Methoden.

Business Logic Layer

Jede DAC ist für ein bestimmtes Geschäftsobjekt zuständig. Geschäftsobjekte repräsentieren z.B. Events, Besucher, Adressen usw. Folgende Möglichkeiten zur Abbildung der Geschäftsobjekte existieren:

• XML-Strings oder XML-Dokumente
• DataSets - das sind im Arbeitsspeicher erzeugte Tabellen. Die Daten können aus einer Datenbank-Tabelle oder einem XML-Dokument stammen. DataSets sind in ADO.NET enthalten.
• Typed DataSets - sie stellen eine Ableitung der o.g. DataSets dar, allerdings stellen sie im Gegensatz zu den normalen DataSets typsichere Methoden, Eigenschaften und Ereignisse bereit.
• Eigene Klassen - jede Klasse stellt ein eigenes Geschäftsobjekt dar. Es werden Felder für die Speicherung der Daten des Geschäftsobjekts definiert, die über die Eigenschaften der Klasse bereitgestellt werden. Weiterhin werden Methoden implementiert, um Geschäftslogik abzubilden, z.B. das Anlegen eines neuen Events. Außerdem stellt die Klasse Methoden zur Übergabe der Daten an den Data Access Layer bereit, um die CRUD-Funktionen für das jeweilige Geschäftsobjekt auszuführen.

Bei dem hier vorgestellten EventManager arbeiten wir mit eigenen Klassen, um die Geschäftsobjekte darzustellen.

Presentation Layer

Der Presentation Layer dient der Präsentation der Geschätslogik und deren Objekten, also der Benutzeroberfläche des EventManagers.

Da der EventManager über eine Website verfügbar sein soll, implementieren wir den Presentation Layer mit ASP.NET 1.1.

Aufgrund der bisher gezeigten mehrschichtigen Architektur des EventManagers wäre auch ohne Änderungen an Presentation und Data Access Layer ein Umstieg von ASP.NET auf WinForms möglich.

Für eine einfache Implementierung und eine leichte Anpassung der Seiten des EventManagers wird das Grundgerüst der Website mit Master Pages realisiert. Hierbei handelt es sich um Seitenvorlagen, die das grundlegende HTML-Layout der Seite beinhalten.

In diesen Vorlagen finden sich dann Platzhalter, über die dann zur Laufzeit ASP.NET UserControls geladen werden, welche die eigentlichen Funktionen wie die Besucherregistrierung oder die Anzeige der Event-Details implementieren:

Die Verwendung von Master Pages in Verbindung mit CSS erlaubt es, die Seite mit wenigen Anpassungen unabhängig von Business Logic und Data Access Layer völlig umzugestalten, wie Sie den folgenden Screenshots entnehmen können:

• Tracks der Veranstaltung
  
• Besucherregistrierung
  
• Besucher-Login
  

Schlußbemerkung

Damit sind wir bereits am Ende unserer kurzen Einführung in die Entwicklung eines EventManagers mit ASP.NET. Wenn Sie sich nun zu Recht fragen, wie z.B. die Administration des EventManagers aussieht, die Daten zwischen den Layern ausgetauscht werden oder die Geschäftsobjekte aussehen: Melden Sie noch heute zur .NET Community Conference vom 4. bis 5. Juni 2004 in Karlsruhe an und erfahren Sie weitere Details zum EventManager. Sie haben außerdem die Möglichkeit, in der Podiumsdiskussion Fragen diesbezüglich sowie zu den Themen der anderen Sessions zu stellen.

Links zu anderen Sites

.NET Community Conference vom 4. bis 5. Juni 2004 in Karlsruhe
.NET Community Conferences

Wenn Sie jetzt Fragen haben...

Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.

Eine weitere sehr hilfreiche Resource ist das deutsche ASP.NET Wiki, das als zentrale Anlaufstelle für Tips, Tricks, Know How und alles Nützliche was man in seinem Alltag als (ASP).NET-Entwickler so braucht und entdeckt gedacht ist.

Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.

Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.