Wechsel zu ORMs

Question

Ich spiele mit dem Gedanken, ein ORM schrittweise in eine von mir unterstützte Anwendung einzuführen.Die App ist nicht sehr strukturiert und verfügt über keine Unit-Tests.Daher ist jede Änderung riskant.Ich mache mir offensichtlich Sorgen, dass ich einen guten Grund habe, mich zu ändern.Die Idee dahinter ist, dass weniger Standardcode für den Datenzugriff erforderlich ist und die Produktivität dadurch gesteigert wird.

Stimmt das mit Ihren Erfahrungen überein?
Ist es möglich oder sogar eine gute Idee, es schrittweise einzuführen?
Was sind die Nachteile eines ORM?

Answer 1

Ich würde dringend empfehlen, sich ein Exemplar von Michael Feathers Buch zu besorgen Effektives Arbeiten mit Legacy-Code (Mit „Legacy Code“ bezeichnet Feathers jedes System, das nicht ausreichend durch Unit-Tests abgedeckt wird.)Es steckt voller guter Ideen, die Ihnen bei der Umgestaltung und Einführung von Best Practices helfen sollen.

Sicherlich könnten Sie die Einführung eines ORM schrittweise durchführen und es zunächst für den Zugriff auf eine Teilmenge Ihres Domänenmodells verwenden.Und ja, ich habe festgestellt, dass die Verwendung eines ORM die Entwicklungszeit beschleunigt – das ist einer der Hauptvorteile, und ich vermisse sicherlich nicht die Zeiten, in denen ich Datenzugriffsebenen mühsam von Hand erstellt habe.

Nachteile von ORM: Erfahrungsgemäß erfordert es zwangsläufig eine gewisse Lernkurve, sich mit den Konzepten, der Konfiguration und den Besonderheiten der gewählten ORM-Lösung auseinanderzusetzen.

Bearbeiten:Name des Autors korrigiert

Answer 2

Das Buch „Robert C. Martin“, das eigentlich von Michael Feathers geschrieben wurde („Uncle Bob“ ist heutzutage anscheinend ein Markenname!) ist ein Muss.

Es ist nahezu unmöglich – ganz zu schweigen davon, dass es wahnsinnig zeitaufwändig ist – Unit-Tests in eine Anwendung zu integrieren, die nicht mit ihnen entwickelt wurde.Der Code ist einfach nicht zugänglich.

Aber das ist kein Problem.Beim Refactoring geht es darum, das Design zu ändern, ohne die Funktion zu ändern (ich hoffe, ich habe die Bedeutung dort nicht zu stark verfälscht), sodass Sie viel umfassender arbeiten können.

Beginnen Sie mit großen Stücken.Richten Sie eine wiederholbare Ausführung ein und erfassen Sie, was passiert, als erwartetes Ergebnis für nachfolgende Ausführungen.Jetzt testen Sie Ihre App oder zumindest einen Teil davon.Sicherlich kein sehr guter oder umfassender Test, aber es ist ein Anfang und von da an kann es nur noch besser werden.

Jetzt können Sie mit der Umgestaltung beginnen.Sie möchten mit dem Extrahieren Ihres Datenzugriffscodes beginnen, damit er ohne allzu große Störungen durch die ORM-Funktionalität ersetzt werden kann.Testen Sie häufig:Bei älteren Apps werden Sie überrascht sein, was kaputt geht.Zusammenhalt und Kopplung sind selten das, was sie sein könnten.

Ich würde mir auch das von Martin Fowler ansehen Refactoring, was offensichtlich das endgültige Werk zu diesem Prozess ist.

Answer 3

Ich arbeite an einer großen ASP.net-Anwendung, in der wir vor kurzem damit begonnen haben, NHibernate zu verwenden.Wir haben eine große Anzahl von Domänenobjekten, die wir manuell auf SQL Server beibehalten hatten, stattdessen nach NHibernate verschoben.Es hat die Dinge erheblich vereinfacht und es viel einfacher gemacht, Dinge im Laufe der Zeit zu ändern.Wir sind froh, dass wir die Änderungen vorgenommen haben und NHibernate gegebenenfalls für viele unserer neuen Arbeiten verwenden.

Answer 4

Ich habe gehört, dass TypeMock häufig zum Refactoring von Legacy-Code verwendet wird.

Answer 5

Ich glaube ernsthaft, dass die Einführung von ORM in eine Legacy-Anwendung Ärger erfordert (und möglicherweise genauso viel Ärger verursacht wie eine komplette Neufassung).

Ansonsten ist ORM ein guter Weg und sollte unbedingt in Betracht gezogen werden.

Answer 6

Die Regel für das Refactoring lautet.Führen Sie Unit-Tests durch.

Vielleicht sollten Sie also zuerst einige Unittests durchführen, zumindest für die Kern-/Hauptaufgaben.

Der ORM sollte für eine Verringerung des Boilerplate-Codes ausgelegt sein.Die Zeit/Ärger vs.Der ROI, um unternehmerisch tätig zu sein, liegt an Ihnen zu schätzen :)

Answer 7

Sofern Ihr Code nicht bereits so strukturiert ist, dass ein „Hot-Swapping“ Ihres Modellebenen-Backends möglich ist, ist eine Änderung in irgendeiner Weise immer äußerst riskant.

Der Versuch, ein Sicherheitsnetz aus Unit-Tests für Code mit schlechter Architektur aufzubauen, garantiert keinen Erfolg, sondern gibt Ihnen nur ein sichereres Gefühl bei der Änderung.

Wenn Sie also keine starken geschäftlichen Argumente dafür haben, die damit verbundenen Risiken einzugehen, ist es wahrscheinlich am besten, die Sache in Ruhe zu lassen.