将 cfmodule 重构为... cfc 的建议？
我自己从来没有写过一行cfmodule。然而，现在是重构的时候了。您通常采取哪些步骤将 cfmodule 重构为 cffunction / .cfc？
我在想...将它们重构为 cffunctions（attributes 变为 arguments），并返回多个值的结构体、单个值的值。然后将相关功能分组到 CFC 中，并将 DB 访问分离到 DAO/网关对象中。对他们每个人进行单元测试。
我的同事在想，也许我们应该为 cfmodules 的每个“流”使用一个 CFC，并使用 obj 的 variables.instance 作用域作为 caller 作用域，然后返回 < code>instance 结构位于“流程”末尾？更容易，但似乎不太可测试。
有人有重构 cfmodule 的经验吗？
I have never wrote a line of cfmodule myself. However, now is the time to refactor. What steps do you usually take to refactor cfmodule into cffunction / .cfc?
I'm thinking... refactor them into cffunctions (attributes becomes arguments), and return struct for multiple values, value for single value. Then group related functions into CFC's, and separate DB access into DAO/Gateway object. Unit test the hell of each of them.
Alternative, my colleague is thinking, maybe we should use a CFC for each 'flow' of cfmodules, and use obj's variables.instance scope as caller scope, then return the instance struct at the end of the 'flow'? Easier, but doesn't seem very testable.
Anyone has exp with refactoring cfmodule's?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
按照您的想法将您的对象重构为 CFC。
根据当前程序使用将应用程序重构为多个部分肯定是错误的方法。基本上，您将业务逻辑硬编码到值对象中，这是不行的。
当需要向现有代码库添加功能时，您会很高兴没有将逻辑与数据组合在一起。 :)
Refactor your objects into CFC's as you're thinking.
Refactoring the application into divisions based off of the current procedural use is the wrong approach for sure. You basically hard coding your business logic to your value objects, which is a no no.
When it's time to add functionality with your existing codebase, you'll be glad you didn't group your logic in with your data. :)