ruby-on-rails - 一个凌乱的 View 层，我应该离开 MVC 吗？

Question

我将问题从 IRC 移到这里。

问题:我已经跳入了一个代码库，我希望它的状态良好。我们不总是这样吗？

本着这种精神，在添加了一些覆盖率(如测试覆盖率)之后，我应用了几个已知的重构/改进来帮助完成这个任务。这就是我所拥有的完成(实际上我做了很多，但这些是我的问题的相关部分):

1. 添加了一些 PORO 对象以卸载在模型、 Controller 甚至 View 中执行的一些任务。
2. 使用 *decent_exposure* 摆脱 View 层所在的实例变量 hell 。
3. 使用 draper 实现了一些 for-views 装饰器，以避免在 View 中有太多逻辑。
4. 为生成多个模型的操作添加了演示者。

现在，我(乐观地)预计所有这一切都会得到返回。它确实更好，但是除了厨房水槽之外的所有东西都被扔掉之后，我本以为它会好很多很多。不是。

因为我有一个 View 层，它实际上在单个操作中渲染了 10-15 个部分，所以我担心我在 Controller 或 View 层中更改内容的能力。每当我决定将帐户的成员称为“成员”或仅称为“用户”时，我不想经历所有这些部分。我很关心这个，因为模型层计划进行更重大的更改。

我最初的想法(并且仍然坚持)是有愚蠢的观点。我希望我的 View 层的大部分完全避免了解它们正在渲染的模型。我想要一个知道如何做两件事的中间对象:从模型中提取它需要的数据，并呈现 HTML。在你告诉我我违反了 SRP 之前，这个对象的真正责任可以理解为“向最终用户显示模型”。

在过于简化的情况下，我希望我的观点(至少是上述观点)看起来像这样:

= some_object.render
= another_object.render

它听起来确实像装饰者模式，也确实像展示者模式，至少我是这么认为的。

然后我开始认为我会严重反对 MVC(至少 Rails 公开的 MVC)，所以我想知道这是否是最好的解决方案(除了明显的，在这个时间限制下几乎不可能, 重写)，所以我对拍摄更有信心。

因此，在这种情况下，我真正的问题归结为:

a) 切换到 MVP、MVVM、MV 是解决此问题的正确解决方案吗？

b) 如果是，您能否告诉我可用于此 some_object.render View 样式的最佳解决方案？

c) 如果不是，能否告诉您如何避免这些部分和一般 View 之间的硬依赖，模型层可能需要几个小时才能被显着重写？

d) 希望你不要到这里:YAGNI，所以之后修复？我很确定我会需要它。

我想到了另一个选项并将其带到了 IRC，虽然不是真正符合标题的精神，但却是一个有效的选项(尽管我认为对于手头的任务来说有点矫枉过正):

e) 添加一个服务层，并使我的 View 映射到该服务层上的“逻辑”模型，这样我就可以独立于 View 更改物理模型。

Answer 1

这个问题很难回答，主要是因为你的确切问题是模糊的。有趣的是，我认为这也是您觉得需要帮助才能前进的原因。

总结:

您已经重构为:

• 愚蠢的观点
• 清晰的 View
• 测试 View

不过，您的主要提示是:

I have a view layer that literally is rendering like 10-15 partials on a single action, I'm concerned about my ability to change things in the controller or the view layer. I don't want to go through all this partials

我会做什么:

我会通过将相关 View 合并在一起来解决“我有太多 View 文件”的问题。

我会通过组织我的 View 来更好地适应代码的实际变化来解决“我找不到我的 View 代码”。

注意事项:

听起来您正面临 2 个反模式:

• 解决方案蔓延(过度分解)
• 过度使用模式

如果 10-15 偏音看起来过多，也许确实如此!每个部分都在代码库中重新使用了吗？它们可以更好地分组吗(这样我就可以渲染 1 个而不是 3 个)？我可以发送一个部分数据来调整其渲染而不是创建 2 个部分吗？

听起来您在“责任分工”上可能走得太远了，大量的观点阻碍了您的工作。也许重组是前进的道路？

寻找 MVP、MVVM 等是错误的方向。沉迷于模式可能会对您造成一些伤害。例如，

# how is this:
= some_object.render

# different from this?
= render "some_object"

View 肯定可以负责“向最终用户显示模型”

我感受到了你的痛苦，有时候代码量本身就是一个问题。组织和分组虽然技术含量低，但却是解决问题的最佳方式。