28.7 Fazit: Typisierte oder nicht typisierte DataSets? 
Nachdem Sie das typisierte DataSet kennengelernt haben, möchte ich einige Eigenschaften auflisten, die Ihnen die Entscheidung für oder gegen die typisierte Form erleichtern sollen.
- Die dynamische automatische Bindung von Daten an ein Windows-Kontrollelement funktioniert nur mit einem typisierten DataSet.
- Beim typisierten DataSet kann der Compiler Sie bei der Fehlersuche durch eine Typprüfung unterstützen. Laufzeitfehler werden damit unwahrscheinlicher.
- Der automatische Codegenerator erstellt ein typisiertes DataSet, das viel komfortabler ist als der SqlDataAdapter. Die eigene Codeerstellung wird dadurch einfacher.
- Das untypisierte DataSet ist flexibler, und die benutzte Abfrage kann zur Laufzeit verändert werden. Im typisierten Fall muss der Quellcode verändert werden, um die Abfrage zu ändern. Dies ist aufwendig, erfordert Hintergrundwissen und ist fehlerträchtig.
- Das typisierte DataSet erhöht den Gesamtumfang einer Anwendung.
- Wenn Sie das typisierte DataSet mit einem geänderten Datenbankschema verwenden, wird eine Ausnahme ausgelöst. Ich betrachte dies als Vorteil, da eine solch fundamentale Änderung der Datenstruktur die gesamte Programmlogik in Frage stellen kann, und dies sollte sich darin äußern, dass das Programm unterbrochen wird.
- Die spezifischen Methoden des typisierten DataSets können prinzipbedingt nicht in der .NET-Dokumentation auftauchen.
Da Sie Zugriff auf den Quelltext eines typisierten DataSets haben, können Sie auch einen Mittelweg gehen. Lassen Sie sich den Quelltext automatisch generieren, und passen Sie das DataSet oder den TableAdapter Ihren Bedürfnissen an. Wenn Sie dabei die Schnittstelle nicht ändern, sondern nur erweitern, können Sie alle Vorteile des typisierten DataSets ohne Verlust an Flexibilität nutzen.
