6

Ich bin in den frühen Phasen der Planung einer Konvertierung einer großen klassischen ASP-Datenbank-Anwendung zu ASP.Net und ich habe Probleme bei der Auswahl, welche Datenzugriffsmethode zu verwenden. Ich habe mit Linq To SQL, Dynamic Data, stark typisierten Datasets, Enterprise Library (Data Access Application Blocks) und ein bisschen mit Entity Framework herumgespielt, aber keiner von ihnen ist mir als "der Eine" erschienen. Es gibt einfach zu viele Möglichkeiten - mein Kopf schwimmt, hilf mir zu wählen!Brauchen Sie Rat bei der Auswahl einer Datenzugriffsmethode?

Vielleicht würde es helfen, einige Hintergrundinformationen über die Anwendung zu geben, die mich mit den Prioritäten ...

  • Das Backend ist Microsoft SQL Server (2005 oder höher) an Umwandlung entlang und wir sind verpflichtet, dass ich mir keine Sorgen darüber machen muss, jemals eine andere Datenbankplattform zu unterstützen.

  • Die Datenbank ist sehr ausgereift und enthält einen Großteil der Geschäftslogik. Es ist hochgradig normalisiert und nutzt umfangreiche gespeicherte Prozeduren, Trigger und Ansichten. Ich möchte lieber nicht zwei Räder gleichzeitig neu erfinden, deshalb möchte ich möglichst wenige Änderungen an der Datenbank vornehmen. Daher muss ich eine Datenzugriffsmethode wählen, die flexibel genug ist, um alle Macken in der Datenbank zu umgehen.

  • Die Anwendung hat viele Dateneingabeformulare und umfangreiche Such-und Reporting-Funktionen (Berichte sind ein anderes Tier, das ich später angehen werde).

  • Die Anwendung muss flexibel genug sein, um kleinere Änderungen an der Datenbankstruktur zu ermöglichen. Die Anwendung (und die Datenbank) kann an verschiedenen Standorten installiert werden, an denen geringfügige benutzerdefinierte Änderungen an der Datenbank vorgenommen werden. Idealerweise könnte die Anwendung die Datenbankerweiterungen identifizieren und entsprechend reagieren. Mit anderen Worten, wenn ich ein O/R-Mapping in der Anwendung speichern muss, muss ich in der Lage sein, das zu ersetzen (oder es einfach zu aktualisieren), wenn ich die Anwendung und die Datenbank an einem neuen Standort installiere.

  • Schnelle Anwendungsentwicklung ist entscheidend. Da die Datenbank bereits fertig ist und die Benutzeroberfläche der vorhandenen Anwendung sehr nahe kommt, hoffe ich, etwas zu finden, wo wir das relativ schnell erledigen können. Ich bin bereit, zu opfern, nicht die absolut späteste und größte Technologie zu verwenden, wenn es Zeit in der Entwicklung spart. Mit anderen Worten, wenn es eine steile Lernkurve für die Verwendung von etwas wie Entity Framework gibt, bin ich gut damit, etwas wie stark typisierte Datasets und eine benutzerdefinierte DAL zu gehen, wenn es den Prozess beschleunigen wird.

  • Ich bin ein totaler Neuling zu ASP.Net, bin aber vertraut mit Classic ASP, T-SQL und der alten ADO (z. B. getrennte Recordsets). Wenn eine der Datenzugriffsmethoden für jemanden, der aus meinem Hintergrund kommt, besser geeignet ist, könnte ich mich in diese Richtung lehnen.

Danke für jede Beratung, die Sie anbieten können!

Antwort

1

nHibernate könnte eine gute Passform sein. Sie können das Mapping in externen Konfigurationsdateien speichern, die Ihre Anforderungen erfüllen. Eine andere Option könnte ActiveRecord sein, die auf nHibernate basiert.

nHibernate hat eine nette Funktion, die Sie hilfreich finden könnten. Es wird eine dynamische Eigenschaft genannt, bei der es sich im Grunde genommen um eine Namenswertpaar-Sammlung handelt, die durch Ziehen der Spaltennamen aus der Zuordnungsdatei gefüllt wird. Wenn Sie also eine Spalte an Ihrer Client-Site hinzufügen, aktualisieren Sie die Zuordnungsdatei, und Sie können über eine Objektgruppe auf die Daten zugreifen.

+0

Mit so vielen Möglichkeiten, das gleiche zu tun, würde ich gerne sehen, was 1 Werkzeug ist gut für andere (d. H. Wann, welche zu verwenden)? zusammen mit der Evaluierung von Tools auf einige Parameter (zB Lernkurve, Wartung, Einfachheit, Community-Unterstützung etc.) – shahkalpesh

+0

Ich habe gehört, dass nHibernate sehr mächtig ist, aber ich habe auch gelesen, dass die Lernkurve ziemlich steil ist, um es zu verwenden richtiger Weg. Leider haben wir diese Zeit nicht. – CowherPower

+0

Wie viel Zeit hast du? Ich brauchte ein paar Tage, um herauszufinden, wie ich mein erstes Objektdiagramm 3 maximal abbilden konnte. Ich bin ein Entwickler von 1, klingt wie du ein Team hast. – JoshBerke

5

Blick auf alle drei Artikel dieser Serie:

High Performance Data Access Layer Architecture Part 1

Großer Rat.

+0

Danke, das war eine sehr interessante Artikelserie. Wenn ich mich entscheide, meine eigene DAL von Grund auf zu erstellen, kann ich diese Methode verwenden. Aber ich muss es in VB umwandeln, da ich C# nicht wirklich gut kenne. – CowherPower

+0

Das meiste wird leicht konvertiert - besonders, wenn Sie ein Tool wie Reflector verwenden, um die Binärdateien nach VB.Net zu zerlegen. Denken Sie auch daran, dass in Ihrer Lösung, selbst wenn Ihre Präsentationsebene vb.net ist, Ihre DAL, DTOs und Business-Schicht C# sein können, wenn Sie in diese Richtung gehen wollten. –

+0

Ich fand auch diese coole Seite, die C# zu VB.net für Sie konvertieren wird. Es scheint ziemlich gut zu funktionieren: http://www.developerfusion.com/tools/convert/csharp-to-vb/ – CowherPower

2

Vielleicht möchten Sie die Datenbankschicht von der Asp-Schicht entkoppeln, so dass Sie nicht nur mehr Flexibilität bei der Entscheidung haben, sondern wenn Sie Änderungen an einer Kundendatenbank vornehmen müssen, können Sie einfach eine neue austauschen dll ohne etwas anderes zu ändern.

Mithilfe der Abhängigkeitsinjektion können Sie mithilfe von XML angeben, welche konkrete Klasse für eine Schnittstelle verwendet werden soll.

Der Vorteil dabei ist, dass Sie dann mit einem Datenbankansatz gehen können, und wenn Sie später zu einem anderen wechseln, dann können Sie einfach die DLL ändern und ohne Änderungen an anderen Ebenen weitermachen.

Da Sie besser damit vertraut sind, warum gehen Sie nicht einfach direkt in die Datenbank, indem Sie Ihre eigenen Verbindungen herstellen? Dann können Sie den Rest Ihres Codes verschieben und auf dem Weg entscheiden, welche der unzähligen Technologien Sie verwenden möchten.

Für eine neue Anwendung, die ich arbeite, starte ich mit LINQ to SQL, hauptsächlich weil die Entwicklung schneller sein wird, aber später, wenn ich entscheide, dass ich meine Bedürfnisse nicht erfülle, werde ich es einfach austauschen.

+0

Wenn Sie sagen "warum nicht einfach direkt in die Datenbank gehen" sprechen Sie über Dinge wie SQLDataSource und Datensätze direkt? Ich bin nicht dagegen, aber ich möchte diesen Weg nicht gehen, wenn die neueren Technologien die "direkte" Methode nicht veraltet (oder eine dumme Wahl) gemacht haben. – CowherPower

+1

Sie können diese URL für die Leistung interessant finden: http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html Ein DataReader wäre vielleicht eine nützliche Wahl. Ich denke nicht, dass der direkte Weg veraltet ist, und wenn es Ihre Entwicklung beschleunigt, um später zu warten, möchten Sie vielleicht ändern. –

+1

Interessanter Artikel. Ich habe mich bereits gegen den Einsatz von Entity Framework gesehnt, und das bestätigt diese Entscheidung. – CowherPower

Verwandte Themen