Codegeneratoren vs. ORMs vs. Gespeicherte Prozeduren

Question

In welchen Bereichen glänzt oder versagt jede dieser Software-Architekturen?

Welche Hauptanforderungen würden Sie veranlassen, sich für die eine oder die andere zu entscheiden?

Bitte gehen Sie davon aus, dass Sie über Entwickler verfügen, die sowohl guten objektorientierten Code als auch gute Datenbankentwicklung betreiben können.

Bitte vermeiden Sie auch heilige Kriege :) alle drei Technologien haben Vor- und Nachteile, ich bin daran interessiert, wo ist am besten geeignet, welche zu verwenden.

Answer 1

Jedes dieser Werkzeuge bietet unterschiedliche Abstraktionsebenen und verschiedene Möglichkeiten, das Verhalten zu überschreiben. Dies sind Architekturentscheidungen, und alle Architekturentscheidungen hängen von Kompromissen zwischen Technologie, Kontrolle und Organisation sowohl der Anwendung selbst als auch der Umgebung, in der sie eingesetzt wird, ab.

• Wenn Sie es mit einer Kultur zu tun haben, in der die DBAs das Sagen haben, ist eine auf gespeicherten Prozeduren basierende Architektur einfacher zu implementieren. Andererseits kann es sehr schwierig sein, Stored Procedures zu verwalten und zu versionieren.

• Codegeneratoren glänzen bei der Verwendung von Sprachen mit statischen Typen, da sie Fehler zur Kompilierzeit und nicht zur Laufzeit abfangen können.

• ORMs sind ideal für Integrationswerkzeuge, bei denen Sie möglicherweise mit verschiedenen RDBMS und Schemata auf einer Installationsbasis arbeiten müssen. Ändern Sie eine Map und Ihre Anwendung arbeitet nicht mehr mit PeopleSoft auf Oracle, sondern mit Microsoft Dynamics auf SQL Server.

Ich habe schon Anwendungen gesehen, bei denen generierter Code als Schnittstelle zu gespeicherten Prozeduren verwendet wurde, weil die gespeicherten Prozeduren so angepasst werden konnten, dass die Einschränkungen des Codegenerators umgangen wurden.

Letztlich hängt die einzig richtige Antwort von dem Problem ab, das Sie zu lösen versuchen, und von der Umgebung, in der die Lösung ausgeführt werden muss. Alles andere ist eine Diskussion über die richtige Aussprache von "Kartoffel".

Answer 2

Ich werde meine Meinung dazu sagen:

Gespeicherte Verfahren

• Kann leicht optimiert werden
• Abstraktion grundlegender Geschäftsregeln, Verbesserung der Datenintegrität
• Bereitstellung eines guten Sicherheitsmodells (keine Notwendigkeit, Lese- oder Schreibberechtigungen für einen frontalen Datenbankbenutzer zu erteilen)
• Glänzen Sie, wenn Sie viele Anwendungen haben, die auf dieselben Daten zugreifen

ORMs

• Sie können sich nur auf die Domäne konzentrieren und haben einen "reineren" objektorientierten Ansatz für die Entwicklung
• Glänzen Sie, wenn Ihre Anwendung datenbankübergreifend kompatibel sein muss
• Glänzen Sie, wenn Ihre Anwendung hauptsächlich vom Verhalten und nicht von Daten gesteuert wird

Code-Generatoren

• Bieten Ihnen ähnliche Vorteile wie ORMs, allerdings mit höheren Wartungskosten und besserer Anpassbarkeit.
• sind ORMs im Allgemeinen insofern überlegen, als ORMs dazu neigen, Kompilierungsfehler gegen Laufzeitfehler einzutauschen, was im Allgemeinen zu vermeiden ist

Answer 3

Ich stimme zu, dass alles seine Vor- und Nachteile hat und viel von der Architektur abhängt. Abgesehen davon versuche ich, ORMs dort einzusetzen, wo es Sinn macht. Ein Großteil der Funktionalität ist bereits vorhanden, und in der Regel helfen sie, SQL-Injection zu verhindern (und das Rad nicht neu zu erfinden).

Bitte beachten Sie die beiden anderen Beiträge zu diesem Thema (dynamisches SQL vs. Stored Procedures vs. ORM) für weitere Informationen

Dynamisches SQL vs. gespeicherte Prozeduren
Was ist besser: Ad-hoc-Abfragen oder gespeicherte Verfahren?

ORMs vs. gespeicherte Prozeduren
Warum ist parametrisiertes SQL, das von NHibernate generiert wird, genauso schnell wie eine Stored Procedure?

Answer 4

ORMs und Codegeneratoren stehen auf der einen Seite des Feldes, Stored Procedures auf der anderen. In der Regel ist es einfacher, ORMs und Codegeneratoren in Greenfield-Projekten zu verwenden, da Sie Ihr Datenbankschema an das von Ihnen erstellte Domänenmodell anpassen können. Bei Legacy-Projekten ist es viel schwieriger, sie zu verwenden, da es schwierig ist, eine Software, die mit einer "data-first"-Mentalität geschrieben wurde, mit einem Domänenmodell zu verbinden.

Dennoch haben alle drei Ansätze ihren Wert. Gespeicherte Prozeduren lassen sich leichter optimieren, aber es kann verlockend sein, in ihnen Geschäftslogik unterzubringen, die in der Anwendung selbst wiederholt werden kann. ORMs funktionieren gut, wenn Ihr Schema mit dem Konzept des ORMs übereinstimmt, können aber andernfalls schwer anzupassen sein. Codegeneratoren können einen guten Mittelweg darstellen, da sie einige der Vorteile eines ORM bieten, aber eine Anpassung des generierten Codes ermöglichen. Wenn Sie sich jedoch angewöhnen, den generierten Code zu ändern, haben Sie zwei Probleme, da Sie ihn bei jeder erneuten Generierung ändern müssen.

Es gibt keine einzig richtige Antwort, aber ich tendiere eher zur ORM-Seite, weil ich glaube, dass es mehr Sinn macht, mit einer objektorientierten Denkweise zu denken.

Answer 5

Gespeicherte Prozeduren

• Vorteile: kapselt den Datenzugriffscode und ist anwendungsunabhängig
• Nachteile: Kann RDBMS-spezifisch sein und die Entwicklungszeit erhöhen

ORM

Zumindest einige ORMs ermöglichen das Mapping auf gespeicherte Prozeduren

• Vorteile: Abstrahiert den Datenzugriffscode und ermöglicht es, Entitätsobjekte auf domänenspezifische Weise zu schreiben
• Nachteile: Möglicher Performance-Overhead und eingeschränkte Mapping-Fähigkeit

Code-Erstellung

• Vorteile: Kann zur Generierung von Stored-Proc-basiertem Code oder einem ORM oder einer Mischung aus beidem verwendet werden
• Nachteile: Die Codegeneratorschicht muss unter Umständen zusätzlich zum Verständnis des generierten Codes gepflegt werden.