Erklärung des Begriffs: ASP.NET Dynamic Data Website (DDS)

Begriff ASP.NET Dynamic Data Website
Abkürzung DDS
Eintrag zuletzt aktualisiert am 31.12.2012

Zur Stichwortliste unseres Lexikons

Was ist ASP.NET Dynamic Data Website ?

Dynamische Datenwebsites (Dynamic Data Sites - DDS, alias DynData) sind ein neues Konzept zum Rapid Application Development (RAD) von datengetriebenen Websites in ASP.NET ab Version 3.5 Service Pack 1. Man erstellt mit LINQ-to-SQL oder dem ADO.NET Entity Framework ein Objektmodell seiner Datenbank. Durch Vorlagen und Konventionen entsteht dann ohne weiteres Zutun des Entwicklers eine komplette Website zur Ansicht der Daten (inkl. Navigation zwischen den in Beziehung stehenden Tabellen) sowie Pflege der Daten. Anschließend kann der Entwickler dieses Grundgerüst an spezielle Bedürfnisse anpassen.

Codename: Jasper
Vorgestellt auf der MIX 2007
erschienen 2008 mit dem Service Pack 1 des .NET Framework 3.5

Grundkonzept

Mit dem Service Pack 1 des .NET Framework 3.5 hat Microsoft einen neuen Ansatz für datengetriebene ASP.NET-Websites vorgestellt, der das Prinzip des RAD noch viel weiter treibt als das SqlDataSource-Steuerelement. Bisher musste der Webentwickler für jede einzelne Tabelle (oder Klasse) die Datenmaske zur Anzeige und Eingabe einzeln anlegen. Dynamische Datenwebsites (Dynamic Data Web Sites) hingegen erzeugen eine Standarddarstellung für ein Objektmodell, das mit Hilfe von LINQ-to-SQL oder dem ADO.NET Entity Framework auf Basis einer Datenbank definiert wurde. Die Datenwebsite enthält Vorlagen für Seitentypen und Spaltentypen, die dann auf allen Datenbanktabellen angewendet werden. Statt mehreren Seiten pro Tabelle gibt es nur wenige Vorlagen. Sonderfälle erschlägt man dann durch eigene Vorlagen.

Die durch Vorlagen generierte Oberfläche bietet die Datenanzeige inklusive Filterung, die Navigation zwischen in Beziehung stehenden Objekten sowie die Änderung dieser Daten inklusive Validierung der Eingaben. Auch das Hinzufügen und Löschen von Objekten ist möglich. Dazu liest ASP.NET zur Laufzeit das Schema des Objektmodells aus und verbindet es mit einer Reihe vordefinierter Seiten- und Feldvorlagen. Anpassungen der Darstellung sind aber durch Annotationen des Modells möglich, der Veränderung der Vorlagen bzw. der Erstellung eigener Vorlagen.

Gegenüber der SqlDataSource unterscheidet sich der Ansatz dadurch, dass der Entwickler in Visual Studio keine spezifischen Seiten für einzelne Klassen erzeugt, die man bei einer Änderung im Modell nur schwerlich synchronisieren kann. Vielmehr kommt eine Reihe von universellen Standardvorlagen zum Einsatz, die sich automatisch an das Modell anpassen. Microsoft spricht davon, ein Grundgerüst (engl. Scaffolding) zu erstellen, das man anpassen kann. Den Begriff "Scaffolding" kennt man schon aus Ruby on Rails, meint aber hier nicht die Codegenerierung zur Entwicklungszeit, sondern die dynamische Erzeugung von Webseiten zur Laufzeit auf Basis vorhandener Metadaten.

Anlegen einer dynamischen Datenwebsite

Für die obigen Administrationsseiten auf Basis einer dynamischen Datenwebsite muss ein Entwickler kaum etwas tun. Würde man die dynamische Datenwebsite getrennt von der eigentlichen Anwendung erstellen und betreiben, wäre sie in drei Handgriffen fertig. Es macht mehr Arbeit, eine dynamische Datenwebsite in eine bestehende Webanwendung einzubauen. Genau das soll hier aber gezeigt werden.

Eine Dynamische Datenwebsite besteht aus verschiedenen Grundelementen, die man nicht von Hand anlegen sollte und möchte. Daher ist der beste Ansatz, auf Basis der Projektvorlage "Dynamic Data Entities Website" ein neues Projekt zusätzlich anzulegen und dann aus diesem Projekt die notwendigen Elemente in das bestehende Projekt zu kopieren.

Anpassen der Ansicht durch Annotationen

Die einfachste Möglichkeit zur Anpassung einer Datenwebsite ist die Anreicherung des Objektmodells mit speziellen Annotationen, die Microsoft im neuen Namensraum System.ComponentModel.DataAnnotations hinterlegt hat. Beispiele für solche Annotationen sind:
[ScaffoldTable] zum Ausblenden von Tabellen bzw. Klassen
[DisplayFormat] zur Formatierung von Ausgaben
[DisplayColumn] zur Beschriftung des Hyperlinks bei verknüpften Daten
[Required] zur Festlegung von Pflichtfeldern bei der Dateneingabe
[Range], [StringLength] und [RegularExpression] zur Definition der erlaubten Eingaben

Da man den generierten Programmcode für die Entitätsklassen nicht verändern sollte (beim nächsten Neugenerieren würden alle Änderungen verloren gehen), nutzt man die Möglichkeiten der partiellen Klassen, um die Annotationen zu platzieren. Die meisten dieser Annotationen wirken auf Attributebene und leider kann man in .NET 3.5 für bereits deklarierte Attribute keine zusätzlichen Annotationen vergeben. Zu jeder Entitätsklasse ist daher als unhübsche Krücke eine weitere Klasse (genannt Metadatenklasse) zu implementieren, in der der Entwickler die Attribute nochmals definieren und dort mit Annotationen versehen muss. Die Annotation MetadataType auf der partiellen Klasse verweist dabei auf die Metadatenklasse.

Namespace DownloadModel
{
// Partielle Klasse zur generierten Entitätsklasse
[MetadataType(typeof(DADownloadAngebotMetaData))]
public partial class DA_DownloadAngebot
{
partial void OnDA_DatumEndeChanging(DateTime? Value)
{
if (value < DateTime.Now) throw new ApplicationException("Endedatum muss in der Zukunft liegen!");
}
}

// Metadatenklasse zur Entitätsklasse
public partial class DADownloadAngebotMetaData
{
[StringLength(10)]
public string DA_Titel;

[StringLength(20)]
public string DA_Text;

[System.ComponentModel.DataAnnotations.UIHint("Key")]
public string DA_ID;
}

// Partielle Klasse zur generierten Entitätsklasse
[MetadataType(typeof(DDDownloadDateiMetaData))]
public partial class DD_DownloadDatei
{
}

// Metadatenklasse zur Entitätsklasse
public partial class DDDownloadDateiMetaData
{
[Range(0,Double.MaxValue)]
public string DD_AnzahlDownloads;
}

}
Listing 1: Durch Annotationen im Objektmodell steuert man das Verhalten der Website

Anpassungen durch Vorlagen

Mit Annotationen und Methoden kann man nur in einem eng abgesteckten Rahmen das Verhalten der generierten Seiten beeinflussen. Wer eine individuellere Darstellung will, muss durch Vorlagen ganze Seiten oder einzelne Felder anpassen. Beim Erstellen des Projekts liegen die Standardvorlagen in den Ordnern /DynamicData/FieldTemplates und /DynamicData/PageTemplates. Es gibt vier Seitenvorlagen für die verschiedenen Ansichtstypen: List.aspx (Tabellendarstellung), Details.aspx (Einzelansicht mit Ändern und Löschen), Insert.aspx (Einzelansicht zum Anfügen von Daten) und ListDetails.aspx (Tabellenansicht mit Einzelansicht der gewählten Zeile darunter, mit Ändern, Anfügen und Löschen). Die Feldvorlagen sind hingegen datentypbezogen und als ASP.NET User Controls realisiert, z.B. Boolean.ascx, DateTime.ascx und Text.ascx aber auch ForeignKey.ascx. Jeweils eine Variante mit "_Edit" im Namen definiert die Darstellung bei einer Dateneingabe.

Kritik

Kritisch an diesem Ansatz ist auch die Untermischung von "oberflächlichen" Informationen in das Objektmodell zu sehen; eine andere Oberfläche für die gleichen Daten erfordert somit ein neues Objektmodell.

Leider muss man die Datenwebsite-Annotationen auf Klassenebene einsetzen und nicht auf Ebene der Attribute, da bei generierten Klassen, die als partiell gekennzeichnet sind, man zwar Attribute hinzufügen kann, nicht aber Annotationen zu bestehenden Attributen hinzufügen kann.

Geschichte

Codename war: Oryx
Früherer Name: Dynamic Data Controls
Erste Erwähnung: MIX07 (Mai 2007)
Erscheinungstermin: Dynamic Data Websites sind im Rahmen von .NET 3.5 Service Pack 1 im August 2008 erschienen.

Details

Namensraum: System.Web.DynamicData

Besondere Steuerelemente:
DynamicControl
DynamicDataManager
DynamicValidator
DynamicField
u.a.

Beratung & Support

Schulungen

Anfrage für eine individuelle Schulung zum Thema ASP.NET DYNAMIC DATA WEBSITE DDS Gesamter Schulungsthemenkatalog