Question

我正在参与一个项目，该项目使用Presenter模式。

我没有看到它的好处，因为Presenter类的所有方法都是微不足道的，如下所示：

class Checkout::NewPresenter

  def initialize(customer, order)
    @customer, @order = customer, order
  end

  def customer
    @customer
  end
  def order
    @order
  end
end

伙计们正在和我说话，这种模式使控制器的测试更加简单。我们从控制器的逻辑中抽象出来，只需要在某些返回值上测试presenter对象。

但是，这种效果可以通过检查控制器的实例变量来实现，而不需要任何presenter层。

我已准备好Simplifying your Ruby on Rails code: Presenter pattern, cells plugin并且仅同意第一个案例：

您的视图中有一些逻辑，它广泛使用您的模型。其他视图中没有这种逻辑的地方。经典的建议是将此代码移动到模型中，但是在很短的时间之后，您的模型会变得臃肿，使用愚蠢的一次性帮助方法。解决方案：模式演示者。

我不理解第二种情况。

您的构造函数包含大量代码，用于从数据库或其他存储中检索视图的某些值。你有很多fragment_exist？当相应的片段已经在缓存中时，调用以确保没有加载您的数据。由于它的大小，测试特定动作真的很难。解决方案：模式演示者。

同样，在控制器测试中，我们只检查实例变量。他们在这里的意思

主要问题是 - 控制器测试的Presenter模式有哪些好处？

Answer 1

我看过Jay Fields关于Rails Presenter模式的演示文稿我发现他的例子很有用，我还没有真正看过其他来自第三方的作品，特别是关于指挥。

对我而言，优点是将模型分离，即与控制器和其他模型完全隔离。我认为这是处理业务逻辑的一种更好的方法，因此控制器保持精简，对底层数据存储及其结构一无所知。但是，原始的Rails Presenter模式有一个很大的问题。演示者对象只是为了呈现它应该位于控制器和视图之间的数据，这就是为什么导体应该是额外的兴趣，因为它们位于模型和控制器之间。

在Enterprise Rails和Full blow域驱动设计一书中提到的逻辑和物理模型也有一些替代方案。

当然，rails世界中的当前解决方案是为模型创建方法，这些模型操纵相关模型将所有业务登录填充到其中。

使用DDD我已经看到了一些幻灯片和rails的提议，但似乎还没有完全实现我希望在不久的将来可以使用带有生成器的宝石。 DDD对于复杂的项目来说是一个有用的选择，不仅如此，而且作为一种替代的设计方法和rails是灵活的，允许代码和模块化扩展，所以我没有看到额外的层和类类型丢失混合问题。 Rails纯粹主义者可能讨厌这个想法，但他们不需要使用它。

Answer 2

您的示例看起来不像典型的演示者。演示者通常包装单个模型，添加其他视图相关逻辑（例如格式化日期），例如通常使用辅助方法。

Checkout对象的上下文是什么，是传递给视图还是在控制器中使用？

如果它在控制器中用于进行两个模型之间的交互，那么它看起来有点像Data Context Interaction的一个方面。

另一方面，如果将对象传递给视图，它看起来像是一个不会做太多的演示者。也许只是为了管理未来的复杂性而进行一些前瞻性思考。

Presenter模式对控制器测试的好处

2 个答案: