在我目前的项目中，我注意到一些事情，
- 业务逻辑的最大部分被移动到助手。
- 将所有帮助文件包含在 lib 目录下的模块中，并将该模块包含在应用程序控制器中。
- 在许多方法中，没有传递参数，而是使用实例变量（在调用方法中创建实例变量并在被调用方法中使用该实例变量）。
- 每个动作都会调用一个辅助方法来执行业务逻辑，该方法将调用其他一些辅助方法。
- 所有方法都写为公共的，没有受保护的和私有的方法。
- 模型仅用于验证。
这些点是否遵循良好的编码约定？如果没有，你能建议我提高性能的最佳编码标准吗？
问问题
236 次
2 回答
3
首先，约定本身与性能无关。
业务逻辑的最大部分被移动到助手。
我会说这是非常糟糕的。流行的成语之一是“胖模型，瘦控制器”，它在大多数情况下都有效。将您可以在模型中的所有业务逻辑放在它们所属的位置。如果您想要简化非常复杂的视图，请使用装饰器（例如 draper gem），然后将业务逻辑（模型）和视图逻辑（装饰器）分离到它们相应的位置。
将所有帮助文件包含在 lib 目录下的模块中，并将该模块包含在应用程序控制器中。
好吧，我想。只要你有一个地方来维护那个链条，感觉还可以。如果它导致误解/误用/乱搞，那么：不行。
在许多方法中，没有传递参数，而是使用实例变量
如果您在谈论模型中的方法：这很好，因为该方法针对您的实例范围，而不是您的类。
每个动作都会调用一个辅助方法来执行业务逻辑，该方法将调用其他一些辅助方法。
听起来很奇怪。控制器负责准备视图中使用的数据。如果您正在帮助器中准备特定数据以将它们分配给您的视图以供使用，请考虑将它们放入装饰器中（如上所述）。但是在几乎每一个动作中都调用一个助手听起来像是做错了事情。
所有方法都写为公共的，没有受保护的和私有的方法。
非公共方法不应该是公共的。看看helper_method和hide_action来自 ActionController。
模型仅用于验证。
错误的。如上所述，模型包含业务逻辑。在控制台中修改东西怎么样？那么，您想手动更新所有逻辑相关数据吗？您现在是否在控制器中“手动”执行此操作（看起来像这样）？当你引入一个 API 时，你是否复制粘贴代码以免错过一些逻辑？当逻辑发生变化时，您真的确定所有需要手动和独立处理该逻辑的端点也会更新吗？
模型有关系、回调和实例方法是有原因的。使用它们！
于 2013-10-16T07:50:32.347 回答
2
表现与你的论点无关；他们是关于项目组织的。
业务逻辑的最大部分被移动到助手
这不应该发生，您应该在模型中移动业务（又名模型）逻辑。Rails 不会强迫您这样做，因此保持逻辑组织取决于开发人员。
模型仅用于验证
这是将业务（又名模型）逻辑置于模型之外的结果。您应该将其从控制器/助手移动到模型。同样，Rails 不会强迫您这样做，所以这取决于开发人员。
将所有帮助文件包含在 lib 目录下的模块中，并将该模块包含在应用程序控制器中。
在许多方法中，没有传递参数，而是使用实例变量（在调用方法中创建实例变量并在被调用方法中使用该实例变量）。
每个动作都会调用一个辅助方法来执行业务逻辑，该方法将调用其他一些辅助方法。
所有方法都写为公共的，没有受保护的和私有的方法。
我认为这些点（更多，更少）与 Rails Helper 设计有关。Rails 的一个缺陷是 Helper 设计：它们与 OO 模式背道而驰，通常最终会变成一堆无组织的函数，就像PHP 一样。
出于这个原因，有些人使用装饰器。装饰器“添加了表示逻辑的 OO 层”（来自Draper），允许更好地组织与视图相关的方法。
如果您想检查该论点，我建议您使用以下链接：
于 2013-10-16T07:59:36.633 回答