Object Datenquelle oder Code-Behind: Was ist besser?

Question

Ich weiß, dass es ein Thema ist, das viele Diskussionen auslösen kann, aber ich würde gerne wissen, was die Leute für die verschiedenen Vor- und Nachteile der Verwendung von Objektdatenquellen halten. Ich mache gerade ein Projekt mit einem anderen Programmierer, dessen Erfahrung und Komfortlevel alle im klassischen ASP verwurzelt sind, und ich bin nicht sicher, welcher Weg zu
geht. A) Erledige den Job schnell b) Erledige den Job mit einem Minimum an Aufwand

Wir haben eine schöne Repository-Schicht mit Domain-Objekten in der Lage, sich selbst zu validieren, so dass die Methoden vorhanden sind, entweder die ODS-Bindung oder Code-Behind-Bindung zu tun.

Ich mag die ODS aus den meisten offensichtlichen Gründen nicht, aber wenn es mich davor rettet, Scrollen/Sortieren/Auswählen/Einfügen/Aktualisieren/Löschen von Szenarien manuell zu programmieren, kann es dann wirklich so schlimm sein?

Answer 1

Objektdatenquellen eignen sich für kleine Projekte, sie skalieren jedoch nicht gut, da Sie Datenschichtinformationen in die UI-Ebene Ihrer Anwendung einbetten. Ich würde vorschlagen, dass Sie sie nur für sehr kleine Anwendungen und Scratch-Pad-Tests verwenden. Wenn Sie eine Designentscheidung treffen, um sie zu verwenden, bereiten Sie sich darauf vor, in Zukunft Probleme mit der Skalierung und Wartung zu haben.

Answer 2

Persönlich denke ich, dass es vom Projekt abhängt. Wenn es sich um eine kleine CRUD-Anwendung mit ein paar Seiten handelt, wird die Bindung an eine Objektdatenquelle wahrscheinlich schnell und einfach sein und wenig Konsequenzen haben.

Wenn es sich um eine groß angelegte Anwendung mit maßgeschneiderten Anforderungen handelt, kann es frustrierend sein, wenn Sie versuchen, eine Objektdatenquelle auf diese spezifischen Anforderungen abzustimmen.

Answer 3

Je vertrauter Sie mit dem zugrunde liegenden ADO.NET-Framework werden, desto weniger werden Sie sich auf die Datenquellensteuerelemente verlassen, die in Visual Studio enthalten sind. Ich habe sie bei den ersten .NET-Projekten, an denen ich arbeitete, religiös verwendet, aber ich fand schnell heraus, dass es viel besser wäre, die Grundlagen des Verbindens und Abrufens von Daten in einer Datenbank zu verwenden bester Versuch, es für mich zu tun.

Ich betrachte sie mehr oder weniger als Trainingsräder, um Sie mit dem Lebenszyklus der Datenbindung mehr oder weniger vertraut zu machen.

Answer 4

Meiner Meinung nach haben beide ihren Platz, ihre Stärken und Schwächen. Die Zeitersparnis beim Kodieren der Elemente, die Sie erwähnen, besonders beim Paging und Sortieren, ist eine große Hilfe, aber wenn Sie etwas Entferntes interessantes mit ihnen machen wollen, werden sie schnell zu Problemen.

Ich verwende ODS, wenn die Daten ausschließlich für die Anzeige verwendet werden. Schlag in ein Datengitter, ein ODS, und du bist fertig. Aber wenn diese Daten irgendwie manipuliert werden müssen, bleibe ich weit weg von all den eingebauten Stücken, keine Gitter, keine ODS.

Answer 5

Ich denke, im Allgemeinen ist Code hinter nützlicher, da es eine zentrale Stelle für die Anpassung von Datenschichtverbindungen bietet. Solange Sie die Aktion in verschiedene Ebenen unterteilen, kann Code dahinter sehr skalierbar sein.

Benutzerdefinierte Objektdatenquellen hingegen sind sehr nützlich, da sie eine inhärente Bindung mit dem GridView-Steuerelement ermöglichen. Das von der benutzerdefinierten Objektdatenquelle bereitgestellte Dataset ermöglicht einfaches Sortieren und Paging. Das benutzerdefinierte Objekt bietet auch eine zentrale Position für den Datenschichtzugriff.

Answer 6

Der größte Vorteil von DataSourceControls besteht darin, dass sie mehrere Bedenken bezüglich des .NET-Lebenszyklus abstrahieren und gleichzeitig vollständige CRUD- und bidirektionale Databinding-Ausdrücke bereitstellen, d. H.<% # Binden ("FirstName")%> (aber 2-Wege-Datenbindungen funktionieren irgendwie, so dass Sie wahrscheinlich nichts verpassen). Als Designmuster ist es eine ziemlich gute Idee mit einer mittelmäßigen Implementierung (ähnlich wie WebForms selbst).

Wenn Sie viewstate deaktivieren und herausfinden, warum Ihre Postbacks nicht bearbeitet werden oder Sie DataBind() an mehreren Stellen aufrufen müssen, können Datenquellen einige der Kopfschmerzen beseitigen, da die DataBoundControls sind intelligent genug, um zu wissen, wann sie Daten benötigen und sie nur von der Datenquelle fordern. Keine DataBind() Aufrufe notwendig.

DataSources bietet auch eine gute Möglichkeit zum Sortieren, Filtern und Paginieren. Die meisten Entwickler verwenden Code-Behind nicht in der Regel Seitenumbruch und stattdessen riesige Ergebnismengen aus der Datenbank.

Der Nachteil von Datenquellen ist, dass es nicht viele gute Implementierungen gab. Und normalerweise binden Sie Ihre Web-Benutzerschnittstelle an Ihre Persistenzimplementierung (zB SqlDataSource, LinqDataSource, etc.) oder Sie verwenden ObjectDataSource, was bedeutet, dass Sie Klassennamen und Methodennamen in Ihrem ASPX fest codieren müssen und verwendet die Reflexion etwas ineffizient. Aus diesem Grund ist es nicht nützlich für Personen, die Abhängigkeitsinjektion oder statische DAO-Klassen verwenden. Es ist eine ziemlich schlecht konzipierte Klasse und scheint fast wie ein nachträglicher Einfall von MS zu sein.

Persönlich würde ich lieber DataSources und den Code-Behind verwenden. Verwenden Sie eine DataSource, um den Lifecycle-/Viewstate-Kopfschmerz zu entfernen, und versehen Sie sie dann mit einem "Select" -Ereignis/Delegate im CodeBehind. Leider kann ObjectDataSource nur Reflektionen verwenden, Sie können jedoch leicht Ihre eigene Implementierung schreiben. Ich habe einen eigenen, aber nicht öffentlich. Doch bevor ich es geschrieben habe habe ich das, was für einige von Object die Unzulänglichkeiten up macht:

http://mikeoff.blogspot.com/2006/06/objectdatasource-working-alternative.html

Answer 7

Object wie jedes andere xxxDatasource in WebForms ist der Koordinator zwischen Business Layer auf große Anwendungen (oder die Data Access Layer auf kleineren) und die Kontrollen selbst.

Es bietet nur Daten und andere Funktionen für den visuellen Teil Ihrer Anwendung, die Benutzeroberfläche durch Ihre Ansichten in Ihrem Datenspeicher.

Benutzer sollten diese Steuerelemente als Anfragen und Antworten für UI-Elemente sehen und aufhören, sie zu missbrauchen oder sie komplett zu verwerfen. Sie sind nicht die DAL, sie sind nicht böse, sie sind nur Verbindungen zu deinen Datenquellen, die kontrollieren können, wie man sehr effizient spricht.

Wenn Sie beispielsweise ein Raster mit Daten haben, die die Quelle basierend auf einer Entscheidung variieren, sollten zwei ObjectDatasources konfiguriert werden und diese Entscheidung sollte auf der Seite und nicht in der ObjectDatasource liegen. Dies ist der bevorzugte Weg, um sie zu verwenden und die Probleme zu vermeiden, die die Leute bei anderen Antworten versuchen.