Portabler Code für Frameworks?

Question

Wir haben uns für die Arbeit mit dem "Insert Framework Here" entschieden.

Wir werden höchstwahrscheinlich auf die nächsthöhere Version des Frameworks aktualisieren, sobald diese auftaucht. Was der oberen Führungsebene jedoch Sorgen bereitet, ist die Frage: "Was ist, wenn das Framework überrollt wird und stirbt und der Code nicht mehr gewartet wird? Die Wahrscheinlichkeit, dass dies geschieht, ist sehr gering, aber ich muss diese Position trotzdem verteidigen.

Ich habe den Rahmen absichtlich nicht erwähnt, um alle Antworten auf die allgemeine Ebene zu beschränken, da ich weiß, dass Diskussionen über den Rahmen hier meist nur Meinungen sind.

Damit komme ich zu der Frage, die sich mir stellt:

Was können wir tun, damit unser Code auf Frameworks portabel bleibt?

Answer 1

Wenn möglich, sollten Sie versuchen, Ihre Geschäftslogik von einer "Interaktionsschicht" zu trennen. Grundsätzlich umschließt diese Interaktionsschicht die Aufrufe an das zugrundeliegende Framework, so dass Ihre Anwendung mit dieser Schicht kommuniziert, die dann zur Kommunikation mit dem Framework verwendet wird.

Auf diese Weise können Sie möglicherweise etwas retten, indem Sie einfach die Interaktionsschicht für ein anderes Framework neu schreiben.

Alternativ können Sie empfehlen, dass Sie Frameworks nicht aktualisieren müssen, nur weil es eine neue Version gibt oder weil das Framework nicht mehr gewartet wird. Häufig wird die Entscheidung für eine Aktualisierung von Technikern getroffen, ohne dass es dafür einen wirklichen geschäftlichen Grund gibt. Sehen Sie sich die Zahl der COBOL- und VB6-Anwendungen an, die noch immer mit wenig oder gar keiner Wartung laufen.

Answer 2

Wenn Sie so viel wie möglich abstrahieren, können Sie sich von Rahmenproblemen fernhalten.

Ich gebe Ihnen ein Beispiel. Ich habe in letzter Zeit angefangen, viel mit Codeigniter zu arbeiten. Ich schätze einige der Dinge, die das Framework tut, aber ich bin kein Fan von anderen Aspekten davon. Eine Sache, die ich nicht mag, ist, dass man so ziemlich für jede Anwendung, die man schreibt, eine eigene Kopie von CI verwenden muss. Wenn CI mit einer neueren Version herauskommt, muss ich zurückgehen und mehrere Anwendungen aktualisieren.

Aus diesem Grund habe ich in meinen CI-Installationen ein separates Verzeichnis mit dem Namen "Base" erstellt und einen PHP-Autoloader eingerichtet, um Klassen daraus laden zu können. Ich habe Dinge wie "Base_controller", "Base_service", "Base_model", usw., und ich verwende diese in allen meinen CI-Installationen. Diese Klassen erweitern die normalen CI-Klassen, und meine Anwendungen erweitern ihrerseits diese Basisklassen. Anstatt eine Controller-Klasse zu schreiben, die die Codeigniter-Klassen erweitert, habe ich zum Beispiel in der ersten Anwendung Controller Klasse, erweitere ich meine Base_controller , was wiederum die CI Controller .

Damit habe ich eine Ebene der Trennung zwischen CI und meinen Anwendungen. Wenn sich CI jemals ändert, sollte ich in der Lage sein, es zu verwalten, indem ich nur meine "Basis" Schicht aktualisiere. Ich kann auch eine Menge Basisfunktionen in dieser Schicht haben und sie nur einmal schreiben, anstatt jedes Mal eine neue Installation von CI zu erweitern.

Die Abstraktion erfordert eine sorgfältige Gestaltung, denn man will es nicht übertreiben. Aber es ist definitiv ein nützliches Werkzeug, um Ihren Code vom Code eines Frameworks zu trennen.

Answer 3

• Prüfen Sie Ihre Alternativen.
• Wählen Sie ein Paar nach folgenden Kriterien:
  • Ähnlichkeit (Vorlagencode, Architektur, Javascript-Bibliotheken)
  • Vielfalt (die natürlich nicht von denselben Personen gepflegt wird)
  • Einfachheit (je einfacher Ihre Frameworks sind, desto weniger Probleme werden Sie bei der Portierung haben)
• Studieren Sie Ihre beiden Alternativen und halten Sie Migrationspfade bereit (d. h. wir müssen dies und jenes neu schreiben und die Datenbankschicht hier optimieren).

Das heißt, wenn PHP Ihre Sprache ist, bezweifle ich sehr, sehr, dass das Zend Framework sterben wird :-)

Answer 4

Wählen Sie ein Open-Source-Framework? Wenn der ursprüngliche Betreuer ausscheidet, können Sie den Code weiter pflegen.

Answer 5

Einige Verteidigungsmaßnahmen könnten sein:

-Adaptermuster

-Wenn es sich um ein Open-Source-Framework handelt, können Sie es selbst entwickeln oder es aufspalten. Dass das Framework nicht mehr entwickelt wird, bedeutet nicht, dass der Code verschwindet.

-Je nach Framework sind die Modelle vom Framework entkoppelt. Z.B. spezifiziert Zend Framework nicht, dass Sie einen aktiven Datensatz verwenden. Ihre Modelle sollten also von der Datenbankschicht entkoppelt sein. Da die Modelle der schwierigste Teil Ihrer Anwendung sind, ist die Anpassung an ein anderes Framework nicht so schwierig, wenn das Modell vom Framework entkoppelt ist (Controller-, View- und Datenbankschicht).