Die Datenzugriffsstrategie weit in ein Projekt zu integrieren?

Question

In einem Projekt haben wir die Datenzugriffsschicht (DAL) mit einem visuellen Designer implementiert, der automatisch eine Menge Code generiert (in unserem Fall: stark typisierte DataSets und DataSetTableAdapters in .NET).

Mit der Quellcodeverwaltung finde ich es jedoch schwierig zu bearbeiten und neue Dinge zum DAL hinzufügen. Wir haben begonnen, den neuen Datenzugriff durch manuelle Schreiben der SQL-Anweisungen (in unserem Fall: ADO.NET SqlCommands etc), die sauberer zu bearbeiten scheint, und vor allem, um die Änderungen in via Source Control zu sehen.

Aber ich mache mir auch Sorgen über das Mischen der Methoden des Datenzugriffs. Was würden Sie vorschlagen? Stick mit der automatischen Generierungsmethode, Continue Converting to 'manuelle' SQL-Anweisungen , wenn Änderungen benötigt werden, oder etwas anderes?

Edit: Inspiriert von den netten Antworten , die das allgemeine Problem der Umstellung der Datenzugriffsstrategie, Ich habe die Formulierung der Frage verallgemeinert.

Die Handhabung der Modelldaten ist nicht sehr objektorientiert. Wir verwenden .NET DataTables anstelle von benutzerdefinierten Objekten.

Answer 1

Wenn Sie zwischen der Konvertierung in manuelle ADO oder der Verwendung von Datasets + Tabellenadapter wählen, sollten Sie besser mit den Datasets arbeiten. Sie erhalten kostenlos CRUD, indem Sie es verwenden, und somit weniger Zeit für die Erstellung und Pflege von SQL verwendet, die keinen Wert gibt.

Übrigens klingt Ihre Frage nicht nach einem objektorientierten Ansatz, der ein Argument dafür sein könnte, vom Datensatz + Tabellenadapter wegzugehen.

Vielleicht möchten Sie auch etwas Forschung/Prototyping in die Domäne OR-mapper + pure objects unternehmen, wenn Sie zunehmend komplexe Geschäftslogik verarbeiten müssen. Es ist jedoch weniger effektiv für den RAD-Ansatz. Ich würde Linq 2 sql auschecken (wenn Sie eine einfache Schema-/Objektstruktur haben und mit der 1: 1-Zuordnung zwischen Objekt und Tabelle zufrieden sind) oder NHibernate, wenn ich Sie wäre. Entity Framework ist nicht ausgereift genug. Die nächste Version wird besser, aber es ist noch lange nicht möglich.

Answer 2

Wenn Sie Ihre DAL komplett neu schreiben, dann sollten Sie vielleicht in ein Persistenz-Framework wie Sprint.NET oder schauen.

Answer 3

... oder SubSonic von Rob Conery :)

sehen zumindest die drei Videos, die Sie in der Projektseite finden.

Answer 4

Ja, bleiben Sie bei dem, was Sie haben und refactor wie nötig und bequem. Ich hasse es, den anderen Antworten zu widersprechen und die Dinge zu verwirren, aber wenn Sie ein anderes Framework für den Datenzugriff verwenden, handeln Sie vielleicht mit einem Systemkopfschmerz für einen anderen. Geh mit deinen Grundlagen, mit denen du dich wohl fühlst.

Answer 5

Gehen Sie zu "nackt" ADO.NET und alle DAL-Arbeit manuell im Code zu tun scheint wie viel Aufwand. Ich würde auf jeden Fall empfehlen, einen OR-Mapper zu betrachten, wie er von anderen empfohlen wurde (NHibernate, Subsonic etc.).

Wenn Ihr Backend in SQL Server und Sie auf .NET 3.0 oder höher sind, könnten Sie auch in Linq2SQL (Gerüchte über seinen Tod sind stark übertrieben) für einfachere Szenarien (1: 1 Zuordnung von Datenbanktabellen zu Ihrer Datenbank) -Schichtenobjekte) oder Entity Framework für komplexere Szenarien (viele Tabellen, viele Vererbung von Objekten in Ihrem Domänenmodell, komplizierte Mapping-Szenarien).

EF hat in letzter Zeit eine Menge schlechten Rap bekommen, was nur teilweise gerechtfertigt ist, IMHO, und die neue Version, EF v4 (fällig mit .NET 4.0 und VS 2010 irgendwann dieses oder nächstes Jahr) sieht wirklich vielversprechend aus.

Marc

Answer 6

Die DAL ist der in der Regel am meisten über-engineered Teil einer Anwendung. Halten Sie es einfach und bauen Sie, was Sie jetzt brauchen oder vernünftigerweise erwarten, sehr bald. SqlCommand, SqlDataReader, etc. sind immer noch relativ abstrakt im Vergleich zu den Grundlagen und Verbindungen, die tatsächlich mit einer Datenbank verbunden, von ihr gelesen und in eine Datenbank geschrieben werden.

Das heißt, Ihr Code wird lesbarer sein, wenn Sie nur einen allgemeinen Ansatz verwenden.