Zukunft des Fusebox-Rahmens

Question

Der gute alte Sicherungskasten war mein erster Rahmen und ich mag ihn immer noch sehr. Begonnen habe ich mit der PHP-Version, derzeit verwende ich die neueste CFML-Version.

Aber die Zeit vergeht, und ich frage mich: Sollte ich vielleicht zu einem anderen Framework wechseln? Nun, ich will hier keinen heiligen Krieg anzetteln. Ich möchte nur die Vor- und Nachteile der weiteren Verwendung von FB kennen.

Ich denke, dass No-XML-Controller eine sehr gute Idee und ein Schritt in die Zukunft sind. Oder vielleicht liege ich falsch und es ist nicht genug und ich sollte mich auf Mach-II oder vielleicht Model-Glue oder ... (geben Sie Ihren Favoriten ein) konzentrieren?

Aber was ist mit PHP? Es scheint, dass es in der Vergangenheit ein wenig stecken geblieben ist. Symfony, CakePHP, Zend usw. sehen jetzt viel besser aus und wachsen schnell.

Es folgt also eine grobe Auflistung der Vergleichsaspekte:

1. Zeitaufwand für Entwicklung und Wartung. Für mich scheint FB hier gut genug zu sein.
2. ORM-Integration. Derzeit bin ich mit eigenen Komponenten (btw, war überrascht, sehr ähnliche Syntax in cf9 Previews zu sehen), aber mit Bedenken über ihre Leistung.
3. Gesamtleistung der Anwendung. Caching? "Geparste" Dateien sind immer noch gut genug?
4. Integration mit anderen Produkten. Zum Beispiel mit Unit-Testing-Tools - hat jemand Erfahrung damit?

Wir freuen uns über jeden Gedanken und jede Meinung. Danke.

Answer 1

In meinem letzten Job habe ich fast ausschließlich FB genutzt. Der größte Teil unserer Codebasis war nicht OO (cfc's gab es noch nicht), so dass die Unterscheidung zwischen Modell und Ansicht uns wirklich geholfen hat. Die Designer wussten, dass sie direkt in den View-Ordner gehen und nicht zu viel an anderen Stellen herumstochern mussten. Die Schaltkreise boten uns eine bessere Möglichkeit, Site-Bereiche abzubilden, als einfach Verzeichnisse zu verwenden. Generell wurden dadurch viele Probleme mit der Seite als Konstrukt gelöst.

Mit der Zeit stelle ich fest, dass der meiste Modell/Controller-Code in cfc's und dao's landet und nur die View-Dateien und Indizes wirklich in .cfm verbleiben, so dass diese Trennung fast natürlich geschieht. Dies führt zu einer neuen Art von Problem, bei dem FB nicht wirklich hilft - die Verwaltung aller cfc's und der daraus resultierenden Objekte sowie Initialisierung und Vererbung. Aus diesem Grund habe ich begonnen, die kalte Quelle Framework, das sich viel mehr auf die Art von Problemen konzentriert, die in modernem OO CF auftauchen, im Gegensatz zu dem seitenbasierten CF, das wir vor Jahren geschrieben haben.