Ich lerne gerade ASP.NET. Ich habe ein paar Bücher zu dem Thema gekauft. Alle davon legen nahe, dass die Verwendung der Datenquellensteuerelemente wie ObjectDataSource / SqlDataSource usw. der richtige Weg ist. Nun, ich bin definitiv kein Experte auf diesem Gebiet, ganz im Gegenteil. aber ich habe das starke Gefühl, dass dies Spielzeugwerkzeuge sind. Es fällt mir schwer zu glauben, dass diese Klassen in einer realen Welt, Unternehmensgrad-Anwendung verwendet werden. Habe ich recht? Oder haben diese Klassen tatsächlich einen Platz in großen Web-Anwendungen?
Danke, Avi
Diese Steuerelemente haben einen schlechten Ruf erlangt, weil sie von unerfahrenen Entwicklern benutzt werden, ohne sie zu verstehen, und professionelle Entwickler, die auf sie herabsehen. Der beste Rat, den ich Ihnen geben kann, ist, dass ein Fachmann das Werkzeug verwendet, das am besten geeignet ist, und das die Arbeit erledigt, ohne dabei in die Quere zu kommen. Wenn diese Tools die Arbeit für Sie erledigen, dann sollten Sie sie verwenden und lassen Sie sich nicht von Leuten dafür abwerben.
Ich stimme Wyatt zu und dachte mir, ich sollte ein bisschen mehr Informationen hinzufügen. Das Problem mit allen Datenquellenobjekten (außer ObjectDataSource) besteht darin, dass Sie Ihre Anwendung nicht in logische Schichten (d. H. UI, Geschäftslogik, Datenzugriff) aufteilen können. Sie geben Ihren gesamten Datenzugriffscode in Ihre Benutzeroberfläche ein, was in einer Architekturansicht Ihres Projekts sehr schlecht ist.
Ich denke, man könnte argumentieren, dass die Verwendung von ObjectDataSource vernünftig ist, vorausgesetzt es redet tatsächlich mit einem realen Objekt der mittleren Ebene. Vor allem, wenn die Entwickler ODS erweitern, um mit ihrer mittleren Ebene zu spielen.
Die anderen werden dir in meinem Laden die Finger brechen (2. Verstoß).
Das erste, was Sie über ASP.NET wissen müssen, ist, dass alles, was mit den Serversteuerelementen und dem Webforms-Paradigma im Allgemeinen zu tun hat, niemals so gut wie Response.Write () sein wird. Die ganze Idee von Webforms besteht darin, Sie so schnell wie möglich von A nach B zu bringen. Bevor Sie sich für Webforms entscheiden, sollten Sie sich fragen: Ist dies der beste Rahmen für meine App? Für stark frequentierte Websites und / oder wenn Sie sich stark um Design-Muster kümmern, würde ich MVC ohne Zweifel wählen.
Wenn Sie jetzt Webformulare auswählen, wird dringend empfohlen, Datenquellensteuerelemente zu verwenden. Es wird dir das Leben leichter machen. Ich weiß nicht, wie Sie Unternehmensanwendungen definieren, aber Datenquellensteuerungen können große Dinge erreichen. Ich empfehle Ihnen, in LinqDataSource, EntityDataSource, die neue DomainDataSource, den neuen QueryExtender und wie diese mit jeder IQueryable-Quelle arbeiten.
Sie eignen sich hervorragend zum Auffüllen eines gebundenen Steuerelements, wenn die Abfrage einfach ist, z. B. eine Dropdown-Liste mit Kategorien. Sie sind ziemlich schmerzhaft für benutzerdefinierte Suchen oder ähnliches. Bewerten Sie Ihren Ansatz von Fall zu Fall.
Konnte nicht mehr zustimmen - das Mischen von Datenbankverbindungskram mit HTML, potentiell Geschäftslogik usw. ist eine sehr schlechte Idee in der modernen Welt der Komponententests, DDD, TDD, etc.
Es wird Situationen geben, in denen sie angemessen sind (vielleicht die einfachsten Berichtsaufgaben, die in Eile erledigt werden müssen, Modelle), aber im Allgemeinen vermeiden Sie sie.
Die Anweisung, dass ein Datenquellen-Steuerelement Code direkt in das Formular einfügt, ist nicht unbedingt eine korrekte Anweisung. Normalerweise haben Sie eine Controller-Klasse und binden das Datenquellen-Steuerelement an die Methode des Controllers.
Sie haben immer noch Ihre mittlere Stufe und was auch immer. Wie ein Poster sagte, sind es meist erfahrene Entwickler, die ruinieren, warum diese Controller wertvoll sind. Sie behandeln alle Installationen für die Seite und Sie haben immer noch eine Trennung zwischen der Benutzeroberfläche und Middle Tier (Controller).
Es kommt aber auch darauf an, ob Sie eher ein oop-Programmierer sind, der Domain-Objekte bevorzugt, die sich gegen Datensätze richten.
Persönlich bevorzuge ich es, Dinge selbst zu verkabeln. Es ist ziemlich einfach, gespeicherte Prozeduren auszuführen, um Daten abzurufen und Dateneintragssteuerelementen zuzuweisen, ohne Datenbindung zu verwenden. Es ist auch einfach, die geänderten Daten zu erfassen und nach Bedarf hinzuzufügen, zu aktualisieren oder zu löschen. Die Datenquellenklassen fügen etwas hinzu, was mir als unnötige zusätzliche Ebene erscheint. Wenn sie wesentlich einfacher wären, als ich es tue, könnte ich ihnen eine Chance geben, aber sie scheinen mir ziemlich komplex zu sein. Und obwohl ich keine Benchmark-Daten habe, um dies zu beweisen, scheinen sie weniger effizient zu sein.
Tags und Links asp.net datasourcecontrol