Im Brennpunkt einfacherer Datenzugriff (Teil 2)
Kommentare

Wie sieht es mit Active Record aus?
Einsteiger und Gelegenheitsentwickler finden es natürlich, sich den Datenzugriff in Form von Laden und Speichern von Daten vorzustellen. Vielleicht hängt das mit der

Wie sieht es mit Active Record aus?

Einsteiger und Gelegenheitsentwickler finden es natürlich, sich den Datenzugriff in Form von Laden und Speichern von Daten vorzustellen. Vielleicht hängt das mit der Ausbildung, die wir erhalten haben (und die wir zu einem großen Teil noch in der Universität bekommen) zusammen, vielleicht ist es aber auch lediglich eine Sache der Einstellung. Im Kern jedoch klingt Datenzugriff wie ein Satz von Werkzeugen, um Daten auf ein persistentes Speichermedium zu schreiben bzw. von dort zu lesen. Das Gefühl dafür, wie einfach eine Datenzugriffstechnologie ist, lässt sich daraus ableiten, wie leicht es ist, eine Abfrage und einen Schreibvorgang einzurichten. Während O/RMs und Entitätsmodell die Flexibilität und Effizienz bieten, die Sie in mehrschichtigen Anwendungen benötigen, fehlt ein gleichermaßen effizientes Framework für einfachere Szenarien.

LINQ to SQL war prinzipiell o.k., außer dass es eine Hybridlösung ist. Dabei stellt LINQ to SQL weder ein O/RM noch ein Active Record dar. Im Ergebnis können Sie mit LINQ to SQL zwar eine Domäne realistisch modellieren, doch haben Sie keine E/A-Operationen für die Objekte, wie man es erwarten würde. Den folgenden Code können Sie mit LINQ to SQL nicht schreiben: var customer = Customer.Load(id);. Stattdessen müssen Sie zu folgendem Code greifen: var customer = from c in database.Customers where c.Id = id select c;. Der Kürze wegen wurden hier die Codezeilen weggelassen, die der LINQ to SQL-Code noch benötigt, um den Datenbankverweis zu initialisieren und das customer-Objekt zu materialisieren. Letztlich ist LINQ to SQL gut für das Modell, das es vorschlägt; es ließe sich aber im Hinblick auf das API noch verbessern, wenn das Ziel darin besteht, LINQ to SQL für das untere Ende von Anwendungen einzusetzen. Wie auch immer man es betrachtet, LINQ to SQL ist ein Stück besser und einfacher als das reine API und die Philosophie von ADO.NET.

Ein Blick auf Microsoft.Data

In das WebMatrix-Paket hat Microsoft den neuen Namespace Microsoft.Data eingebunden. Er enthält einige neue Objekte, die für den Datenzugriff etwa in der Art wie ADO.NET vorgesehen sind, aber eine einfachere und direktere Syntax bietet:

var db = Database.Open("Northwind"));
var command = "SELECT * FROM customers WHERE country = "USA";
var customers = db.Query(command);
foreach (var c in customers) 
{        
    Response.Write(c.CompanyName);    
}
db.Close();  

Dieses neue Datenzugriffs-API ist auf das Database-Objekt ausgerichtet, mit dem Sie SQL-Server-Datenbanken öffnen können, die im App_Data-Ordner der ASP.NET-Anwendung eingebunden sind. Der Methode Open oder OpenFile übergeben Sie eine Zeichenfolge entsprechend dem Namen der App_Data-Datenbankdateien, die eine der beiden unterstützten Erweiterungen SDF und MDF verwenden: var db = Database.OpenFile(„StarterSite.sdf“);. Das SDF-Format stammt von SQL Server Compact Edition; das MDF-Format ist das klassische Format, das von SQL Server unterstützt wird. Außerdem können Sie der Methode Open eine mit Database.RegisterConnectionString registrierte Verbindung sowie eine Verbindungszeichenfolge von web.config übergeben. Derzeit befindet sich dieses API erst im CTP-Status und kann sich in Zukunft noch beträchtlich ändern, sodass ich hier nicht weiter auf Details eingehe. In erster Linie wollte ich mit diesem Artikel zeigen, dass der Datenzugriff eine zu ernste Angelegenheit ist, um ihn falsch zu verstehen.

Microsoft.Data ist ein weiteres Framework für den Datenzugriff, doch keines, das Entwickler dem bereits überquellenden Korb von Auswahlmöglichkeiten hinzufügen sollten. Als aktiver Entwickler/Architekt arbeiten Sie wahrscheinlich mit LINQ to SQL, Entity Framework und NHibernate bereits genügend produktiv, um getrost dieses neue Framework zu ignorieren und ohne irgendetwas zu vermissen. Wenn Sie als Hobbyprogrammierer in Aktion treten (d. h. eine witzige Site erstellen müssen, um Ihrem Sohn zu helfen, seine Freunde zu beeindrucken), dann ist dieses Framework wahrscheinlich besser als ADO.NET geeignet und Sie werden damit möglicherweise schneller als je mit LINQ to SQL klarkommen. Doch seien Sie sich auch bewusst, dass Sie die Entwicklung von einer einzigartigen nichtprofessionellen Sicht angehen, wo Sie sich nicht um Komponententests, Wartung, SQL-Injection, Transaktionsfähigkeit, Parallelität und ähnliche Dinge kümmern müssen.

Voraussichtlich wird es in der nächsten Zeit einige Verwirrung und Aufregung über die tatsächliche Rolle und Perspektive um Microsoft.Data geben. Nehmen Sie deshalb diesen Artikel als meinen bescheidenen Versuch, die Dinge in das (meiner Meinung nach) rechte Licht zu rücken.

Dino Esposito ist R&D Director bei Crionet, einer Firma, die sich auf webbasierte Lösungen für Sportereignisse in ganz Europa spezialisiert hat (http://www.e-tennis.net). Außerdem ist Dino der Autor von „Programming ASP.NET MVC“, Microsoft Press, 2010.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -