Ich brauche wirklich eine ehrliche, durchdachte Debatte über die Vorzüge der derzeit akzeptierten Unternehmensanwendung Entwurfsparadigma.
Ich bin nicht davon überzeugt, dass es Entitätsobjekte geben sollte.
Mit Entitätsobjekten meine ich die typischen Dinge, die wir für unsere Anwendungen zu erstellen pflegen, wie "Person", "Konto", "Bestellung", usw.
Meine derzeitige Design-Philosophie lautet wie folgt:
- Der gesamte Datenbankzugriff muss über gespeicherte Prozeduren erfolgen.
- Wann immer Sie Daten benötigen, rufen Sie eine gespeicherte Prozedur auf und iterieren über einen SqlDataReader oder die Zeilen in einer DataTable
(Hinweis: Ich habe auch Unternehmensanwendungen mit Java EE entwickelt, Java-Fans ersetzen bitte das Äquivalent für meine .NET-Beispiele)
Ich bin nicht gegen die OO. Ich schreibe viele Klassen für verschiedene Zwecke, nur nicht für Entitäten. Ich gebe zu, dass ein großer Teil der Klassen, die ich schreibe, statische Hilfsklassen sind.
Ich baue kein Spielzeug. Ich spreche von großen, hochvolumigen Transaktionsanwendungen, die auf mehreren Rechnern eingesetzt werden. Webanwendungen, Windows-Dienste, Webdienste, B2B-Interaktion, was immer Sie wollen.
Ich habe OR Mappers verwendet. Ich habe ein paar geschrieben. Ich habe den Java EE Stack, CSLA und ein paar andere Äquivalente verwendet. Ich habe sie nicht nur verwendet, sondern diese Anwendungen aktiv in Produktionsumgebungen entwickelt und gepflegt.
Ich bin zu dem kampferprobten Schluss gekommen, dass uns die Objekte der Entität im Weg stehen und unser Leben also viel einfacher ohne sie.
Ein einfaches Beispiel: Sie erhalten einen Support-Anruf wegen einer bestimmten Seite in Ihrer Anwendung, die nicht richtig funktioniert, vielleicht wird eines der Felder nicht so persistiert, wie es sein sollte. Bei meinem Modell öffnet der mit der Suche nach dem Problem beauftragte Entwickler genau 3 Dateien . Eine ASPX, eine ASPX.CS und eine SQL-Datei mit der gespeicherten Prozedur. Das Problem, bei dem es sich um einen fehlenden Parameter für den Aufruf der gespeicherten Prozedur handeln könnte, lässt sich innerhalb von Minuten lösen. Aber bei jedem Entitätsmodell werden Sie unweigerlich den Debugger einschalten, den Code durchgehen und am Ende vielleicht 15-20 Dateien in Visual Studio geöffnet haben. Wenn Sie dann bis zum Ende des Stapels vorgedrungen sind, haben Sie vergessen, wo Sie angefangen haben. Wir können nur so viele Dinge auf einmal im Kopf behalten. Software ist unglaublich komplex, ohne dass man unnötige Schichten hinzufügen muss.
Die Komplexität der Entwicklung und die Fehlersuche sind nur eine Seite meines Ärgers.
Lassen Sie uns nun über die Skalierbarkeit sprechen.
Ist den Entwicklern bewusst, dass sie jedes Mal, wenn sie einen Code schreiben oder ändern, der mit der Datenbank interagiert, eine gründliche Analyse der genauen Auswirkungen auf die Datenbank durchführen müssen? Und zwar nicht nur die Entwicklungskopie, sondern eine Nachahmung der Produktion, damit Sie sehen können, dass die zusätzliche Spalte, die Sie jetzt für Ihr Objekt benötigen, den aktuellen Abfrageplan ungültig macht und ein Bericht, der in einer Sekunde lief, jetzt zwei Minuten braucht, nur weil Sie der Auswahlliste eine einzelne Spalte hinzugefügt haben? Und es stellt sich heraus, dass der Index, den Sie jetzt benötigen, so groß ist, dass der DBA das physische Layout Ihrer Dateien ändern muss?
Wenn Sie zulassen, dass sich die Mitarbeiter mit einer Abstraktion zu weit vom physischen Datenspeicher entfernen, werden sie bei einer Anwendung, die skaliert werden muss, Schaden anrichten.
Ich bin kein Eiferer. Ich kann mich überzeugen lassen, wenn ich falsch liege, und vielleicht tue ich das auch, da es einen so starken Schub in Richtung Linq to Sql, ADO.NET EF, Hibernate, Java EE, etc. gibt. Bitte denken Sie über Ihre Antworten nach. Wenn ich etwas übersehe, möchte ich wirklich wissen, was es ist, und warum ich mein Denken ändern sollte.
[Bearbeiten]
Es sieht so aus, als ob diese Frage plötzlich wieder aktiv ist. Da wir jetzt die neue Kommentarfunktion haben, habe ich mehrere Antworten direkt kommentiert. Vielen Dank für die Antworten, ich denke, dies ist eine gesunde Diskussion.
Ich hätte wohl deutlicher sagen sollen, dass ich von Unternehmensanwendungen spreche. Ich kann mich wirklich nicht zu einem Spiel äußern, das auf dem Desktop eines Anwenders läuft, oder zu einer mobilen Anwendung.
Eine Sache, die ich als Antwort auf mehrere ähnliche Antworten hier an den Anfang stellen muss: Orthogonalität und Trennung von Belangen werden oft als Gründe für die Einführung von Entity/ORM angeführt. Gespeicherte Prozeduren sind für mich das beste Beispiel für die Trennung von Belangen, das ich mir vorstellen kann. Wenn Sie alle anderen Zugriffe auf die Datenbank außer über gespeicherte Prozeduren verbieten, könnten Sie theoretisch Ihr gesamtes Datenmodell umgestalten, ohne den Code zu verändern, solange Sie die Eingaben und Ausgaben der gespeicherten Prozeduren beibehalten. Sie sind ein perfektes Beispiel für Vertragsprogrammierung (solange Sie "select *" vermeiden und die Ergebnismengen dokumentieren).
Fragen Sie jemanden, der schon lange in der Branche tätig ist und mit langlebigen Anwendungen gearbeitet hat: Wie viele Anwendungs- und Benutzeroberflächenschichten sind gekommen und gegangen, während eine Datenbank weitergelebt hat? Wie schwer ist es, eine Datenbank zu optimieren und zu überarbeiten, wenn es 4 oder 5 verschiedene Persistenzschichten gibt, die SQL generieren, um an die Daten zu gelangen? Sie können nichts ändern! ORMs oder jeder Code, der SQL generiert Ihre Datenbank in Stein meißeln .
