我们的Intranet和网站有一个中等规模的ColdFusion代码库。对于代码的大部分历史记录，我们在cfm中使用了硬编码链接，以便将代码转换为“保存”代码。
在过去的几年里，我们开始使用cfc来处理更多的“导航”代码以及更自动化的保存代码（隐式调用init上给定cfc的保存过程）
假设开始使用框架是有意义的，开始将它用于新项目或尝试全面转换是否更好？
修改的
为了避免混淆，我感觉到通过转向更多基于cfc的代码，我们正在走上意外创建自己的框架的道路。在我看来，采取适当的框架并允许cfc处理数据的主动步骤可能是一个更明智的选择。
答案 0 :(得分：5)
如果你花费超过10-20％的时间维护项目，我只会付出努力。 （你的门槛低或高。）除此之外，只将其用于新项目。
为什么呢？我认为转换将是痛苦的，费力的，并且可能浪费宝贵的时间。
答案 1 :(得分：3)
“假设开始是有道理的 使用框架，是否更好 开始将它用于较新的项目或 尝试全面转换？“
我想说你是否应该转向框架的最大标准是：
根据应用程序的大小，将当前应用程序转换为框架可能是值得的，如果通过简化维护并减少代码重复以便将来添加到当前项目，可以节省更多时间。如果您很少维护应用程序，除了在这里和那里进行一些调整，那么我会说不管它，只使用框架用于新的应用程序。
答案 2 :(得分：1)
框架具有短期成本和长期收益。
当我们开始没有一个时，我们通常会间接地开始构建一个，以增加代码的重复使用，并使事情更有条理。
我一直是Fusebox的忠实粉丝，可能是因为我刚刚使用它已经很久了。
我过去所做的是，如果我知道该网站永远不会更新到任何真正的网站功能，我只需滚动自己的cfswitch来在动作之间导航。每个动作我简单地分解成dsp act qry类型文件的fusebox喜欢。
如果我需要将它放入保险丝盒，我的大部分电路和动作都已完成。前进的道路有点容易。
另一方面，如果我知道客户可能会在未来想要更多，我会把它放在一个框架中并留在那里。
在旁注中，我也一直在查看非常令人印象深刻的ColdBox - 它似乎有一些非常棒的支持，可扩展性以及记录非常好的cfc密集...也可以查看它们。
答案 3 :(得分：0)
您是否考虑使用fusebox这样的框架而不是自己滚动？如果您开始在新项目上使用框架，那么您可能会更容易将您学到的知识应用到现有项目中。