好老Fusebox是我的第一个框架，我仍然非常喜欢它。从PHP版本开始，目前使用最新的CFML版本。
但时间过去了，我想知道：也许我应该切换到另一个框架？好吧，我不想在这里开始圣战。我只是想知道继续使用FB的优点和缺点。
说，我认为没有XML控制器是非常好的想法，并迈向未来。或者也许我错了，这不是因为我应该专注于Mach-II或者Model-Glue或......（输入你最喜欢的）？
但是PHP怎么样？似乎它已经过去了一段时间。 Symfony，CakePHP，Zend等现在看起来好多了，并且发展得很快。
因此，比较方面的粗略列表如下：
任何想法和意见都表示赞赏。感谢。
答案 0 :(得分：8)
Fusebox仍在积极开发中，最近刚转手，因此首席开发人员现在Adam Haskell。
您应该切换到另一个框架吗？
这是一个主观问题。唯一的好答案是 - 给予无限的时间和机会 - 你应该尝试所有，看看你喜欢什么。他们都有自己的优点和缺点，但大多数人都认为这不是哪个框架的问题，而是 框架的问题。你已经确定它是你想要的工具，对你有好处。使它成为您理解和享受的工具。
尽管如此，时间和机会并不总是可用的。在这种情况下，您可能最好坚持使用您所了解的内容，并了解Fusebox的最新更改。我没有时间自己学习它们，所以我自己一直是模特胶水的人。我在不久的将来会看到一些Fusebox，但同样，它是主观的，重要的是你在你的情况下做的最好。
<强> PHP
我无法真正谈论PHP框架的状态，因为我是CFML开发人员。同样，如果你有时间，可以和他们一起玩，评估他们在哪里以及他们是否是你有兴趣使用的工具。
ORM整合
我知道Model-Glue有ORM集成 - Reactor和Transfer都很容易挂钩。我怀疑Mach-II可能也是如此，也可能是Fusebox，但我对这两者都不肯定。
在Hibernate中出现的ColdFusion 9可能在任何框架中都能很好地工作，但还有待观察。
效果/缓存;解析文件？
这更像是ColdFusion与.Net的问题，对吧？ PHP也是一种“解析”语言。预编译的二进制代码在运行时总是至少有一点点优势，但考虑到对于大多数Web应用程序来说，添加一些功能更强大的硬件比花费额外几个月（或更多）开发软件更容易，也更便宜。 / p>
“解析”文件仍然足够好吗？是!哎呀！
整合＆amp;测试框架
有多个测试框架，包括CFUnit，CFCUnit和MXUnit，用于单元测试（适用于TDD），CFSpec适用于BDD。我相信还有很多其他人。
CF8带来了与.Net和Exchange的集成（以及可能还有其他一些我忘记的事情），并且我们已经从版本6开始与Java集成。将一些组件写成“mash-up”从未如此简单用这些不同的语言来获得最好的世界。
<强>结论
你的问题标题是关于Fusebox框架的未来，我可以告诉你它不会去任何地方（除了继续增长和改进，就像其他CFML框架......）。如果您对Fusebox感到满意，可能没有理由离开它。这并不意味着你不应该尝试一切，但没有理由放弃发货。
答案 1 :(得分：3)
扩大视野不会有害：
比较范围非常广泛，您无法在单个SO线程中获得针对您的四个标准的全面且精确定制的答案。这是一个很好的问题，但没有一个答案是肯定的。
相反，我会问（如果有的话）会阻止你尝试不同的框架并扩展你的视野（假设你的专属或主要经验是FB）。
从第一手经验来看，没有什么能超越你自己对四项标准的评价，特别是因为你要问的是那些非常主观或合理解决的因素。
特别向FB致敬：
即使在大多数人听说过XML或Web框架之前，Fusebox框架也起源并获得了动力。这是第一个“烦恼破坏”的Web开发框架之一，旨在让Web应用程序开发更加“有趣”（目标是消除ColdFusion的一些烦恼和乏味，ColdFusion本身就是当时的特殊框架） 。
因此，它已经走过了漫长的道路并拥有相对强大的跟踪记录（就像ColdFusion一样）。
但是，有些人认为这对FB有重大损害（就像ColdFusion一样）。框架中有很多“包袱”，如果它与许多其他MVC框架的年龄相同，并且作为“新的孩子”在街区获得可信度，那么坦率地说就不会存在。如果你选择FB作为完成任务的独家方式，那么（从语言设计的角度来看）有很多方面可以揭示一些可能会对你的Web应用程序框架思维方式产生负面影响的粗糙边缘。
没有命名，（你已经听过了）我建议你最好把FB保留在你的工具箱上，但也要分支到更新的框架，尤其是那些基于编程语言其他而不是PHP和ColdFusion。
通过这种方式，您还可以扩展您作为程序员的视野和理解。
答案 2 :(得分：2)
在工作中我们使用Fusebox（php）...... IT SUCKS !!
如果可能的话，我肯定会建议迁移一个更“时髦”的框架。
虽然.. 我所做的，这似乎可以缓解我对框架的大部分兴趣，就是编写模板文件，包括交换机中的模板文件，以及计算同一个case语句中的任何“运行时”参数。这促进了良好的代码重用。
但我的意思是...... 有一个巨大的开关声明？不是代码闻到“这应该是一个对象吗？”。 它让我想起了一个RoR控制器类的程序版本。 （我不是一个RoR家伙......只是说）
答案 3 :(得分：1)
如果您正在寻找一个Rails类型框架，请查看cfwheels。
答案 4 :(得分：1)
过了一段时间，我们可以说Fusebox比活着还要死。
Status of FuseNG在Google网上论坛。
答案 5 :(得分：0)
我在上一份工作中几乎完全使用了FB。我们的大多数代码库都是非OO（cfc尚未存在），因此模型/视图的区别确实对我们有所帮助。设计师知道要直接进入视图文件夹，而不是在其他地方逛太多。 Circuits为我们提供了一种比仅使用目录更好的映射站点区域的方法。一般来说，它解决了页面作为构建工作方式的许多问题。
随着时间的推移，我发现大多数模型/控制器代码最终只在cfc和dao中只有视图文件，并且索引真的保留在.cfm中，所以这种分离几乎是自然而然的。这就产生了一种新的问题，FB并没有真正帮助它 - 管理所有cfc和结果对象以及初始化和继承。因此我开始使用coldspring框架，它更多地关注现代OO CF中出现的问题，与我们几年前写的基于页面的CF相关。