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

Fusebox wird immer noch aktiv weiterentwickelt und hat erst kürzlich den Besitzer gewechselt, so dass der Hauptentwickler jetzt Adam Haskell .

Sollten Sie zu einem anderen Framework wechseln?

Das ist eine subjektive Frage. Die einzige gute Antwort ist, dass man - wenn man unendlich viel Zeit und Gelegenheit hat - alle ausprobieren sollte, um zu sehen, was man bevorzugt. Sie haben alle ihre Vor- und Nachteile, aber die meisten Leute sind sich einig, dass es nicht eine Frage von die Rahmen als auch eine Frage der zu Rahmen. Sie haben bereits entschieden, dass Sie dieses Werkzeug in Ihrem Gürtel haben wollen, das ist gut für Sie. Machen Sie es zu einem Werkzeug, das Sie verstehen und genießen.

Allerdings sind Zeit und Gelegenheit nicht immer vorhanden. In diesem Fall ist es wahrscheinlich am besten, bei dem zu bleiben, was man kennt, und zu lernen, was mit den letzten Änderungen an Fusebox neu ist. Ich selbst habe nicht die Zeit, alles zu lernen, deshalb habe ich mich für Model-Glue entschieden. Ich sehe Fusebox in meiner nahen Zukunft, aber wie gesagt, es ist subjektiv und wichtig ist, dass Sie das tun, was in Ihrer Situation am besten funktioniert.

PHP

Zum Status von PHP-Frameworks kann ich nicht viel sagen, da ich CFML-Entwickler bin. Auch hier gilt: Wenn Sie die Zeit haben, spielen Sie mit ihnen und bewerten Sie, wo sie stehen und ob sie ein Tool sind, das Sie verwenden möchten.

ORM-Integration

Ich weiß, Model-Glue hat ORM Integration -- Reaktor y Übertragung Beide lassen sich sehr leicht einhaken. Ich vermute, dass dasselbe für Mach-II und wahrscheinlich Fusebox gesagt werden kann, aber ich bin mir bei beiden nicht sicher.

Das in ColdFusion 9 eingebaute Hibernate wird wahrscheinlich in jedem Framework gut funktionieren, aber das muss sich erst noch zeigen.

Leistung / Zwischenspeicherung; Geprüfte Dateien?

Das ist eher eine Frage zwischen ColdFusion und .Net, oder? PHP ist auch eine "geparste" Sprache. Vorkompilierter Binärcode wird immer zumindest einen leichten Vorteil bei der Laufzeit haben, aber bedenken Sie, dass es für die meisten Webanwendungen einfacher und kostengünstiger ist, etwas leistungsfähigere Hardware hinzuzufügen, als ein paar Monate (oder mehr) mehr in die Entwicklung der Software zu investieren.

Sind "geparste" Dateien immer noch gut genug? Ja! Aber ja!

Integration und Test-Rahmenwerke

Es gibt mehrere Test-Frameworks, darunter CFUnit, CFCUnit und MXUnit, die mir spontan für Unit-Tests einfallen (die sich gut für TDD ), und CFSpec para BDD . Ich bin sicher, es gibt noch viele andere.

CF8 brachte die Integration mit .Net und Exchange (und wahrscheinlich noch ein paar andere Dinge, die ich vergessen habe), und wir haben die Integration mit Java seit Version 6. Es war noch nie so einfach, Komponenten, die in diesen verschiedenen Sprachen geschrieben wurden, miteinander zu kombinieren, um das Beste aus allen Welten zu erhalten.

Schlussfolgerung

Der Titel Ihrer Frage bezieht sich auf die Zukunft des Fusebox-Frameworks, und ich kann Ihnen sagen, dass es nirgendwo hingeht (außer um weiter zu wachsen und sich zu verbessern, wie die anderen CFML-Frameworks...). Wenn Sie mit Fusebox zufrieden sind, gibt es vielleicht keinen Grund, es zu verlassen. Das heißt nicht, dass Sie nicht alles ausprobieren sollten, aber es gibt keinen Grund, das Schiff zu verlassen.

Answer 2

Es kann nicht schaden, seinen Horizont zu erweitern:

Die Bandbreite der Vergleiche ist so groß, dass Sie in einem einzigen SO-Thread unmöglich eine umfassende und genau auf Ihre vier Kriterien zugeschnittene Antwort erhalten können. Es ist eine gute Frage, aber eine, auf die keine einzelne Antwort endgültig sein wird.

Stattdessen würde ich fragen, was (wenn überhaupt) Sie davon abhält, einen anderen Rahmen auszuprobieren und Ihren Horizont zu erweitern (vorausgesetzt, Sie haben bisher ausschließlich oder hauptsächlich Erfahrungen mit FB gemacht).

Nichts wird Ihre eigene Bewertung Ihrer vier Kriterien aus eigener Erfahrung übertreffen, zumal Sie nach Faktoren fragen, die entweder sehr subjektiv sind oder von jedem "hochkarätigen" Webanwendungs-Framework auf dem Markt angemessen berücksichtigt werden.

Ein Hinweis auf FB im Besonderen:

Das Fusebox-Framework entstand und gewann an Dynamik, noch bevor die meisten Menschen von XML oder Web-Frameworks gehört hatten. Es war eines der ersten Web-Entwicklungs-Frameworks, das die Entwicklung von Web-Apps "unterhaltsamer" machen sollte (mit dem Ziel, einige der Ärgernisse und die Langeweile von ColdFusion zu beseitigen, das selbst ein außergewöhnliches Framework für seine Zeit war).

Folglich hat es einen langen Weg hinter sich und verfügt über eine relativ solide Erfolgsbilanz (genau wie ColdFusion).

Dies kann jedoch von einigen als erheblicher Nachteil gegenüber FB angesehen werden (ebenso wie bei ColdFusion). Es gibt eine Menge "Ballast" im Framework, der offen gesagt nicht vorhanden wäre, wenn es gleich alt wäre wie viele der anderen MVC-Frameworks, die als die "neuen Kinder" im Block an Glaubwürdigkeit gewinnen. Es gibt viele Aspekte, die (vom Standpunkt des Sprachdesigns aus) einige raue Kanten aufweisen, die Ihre Denkweise über Webanwendungs-Frameworks negativ beeinflussen könnten, wenn Sie FB als ausschließliche Methode zur Erledigung Ihrer Aufgaben wählen.

Ohne Namen zu nennen (Sie haben sie bereits gehört), würde ich vorschlagen, dass Sie FB in Ihrem Werkzeuggürtel behalten, aber auch in die neueren Frameworks abzweigen sollten, insbesondere solche, die auf Programmiersprachen beruhen autre als PHP und ColdFusion.

Auf diese Weise werden Sie auch Ihren Horizont und Ihr Verständnis als Programmierer im Allgemeinen erweitern.

Answer 3

Bei der Arbeit verwenden wir Fusebox (php)... ES SCHLÄGT!!

Wenn es irgend möglich ist, würde ich auf jeden Fall vorschlagen, ein "angesagteres" Framework zu migrieren.

Obwohl Was ich tue, und dies scheint zu aleviate die meisten meiner Beschwerde mit dem Rahmen, ist zu schreiben, Template-Dateien, enthalten, dass aus dem Schalter, und auch berechnen alle "Laufzeit" Parameter innerhalb der gleichen Fall-Anweisung als gut. Das fördert eine gute Wiederverwendung von Code.

Aber ich meine mit 1 großen switch-Anweisung? Ist das nicht ein Codegeruch für "dies sollte ein Objekt sein?". Es erinnert mich an eine prozedurale Version einer RoR-Controller-Klasse. (Ich bin kein RoR-Kenner ich sage nur)

Answer 4

Wenn Sie nach einem All-in-One-Rails-Framework suchen, schauen Sie sich cfwheels an.

http://www.cfwheels.com

Answer 5

Nach einiger Zeit können wir sagen, dass Fusebox mehr tot als lebendig ist.

1. FuseNG-Aktualisierung von A. Haskell

2. Status von FuseNG bei Google Groups.