2

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

我没有看到它的好处，因为 Presenter 类的所有方法都是微不足道的，就像这样：

class Checkout::NewPresenter

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

  def customer
    @customer
  end
  def order
    @order
  end
end

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

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

我已经准备好简化您的 Ruby on Rails 代码：Presenter 模式、单元格插件，并且仅同意第一种情况：

您的视图中有一些逻辑，它广泛使用您的模型。在其他视图中没有任何地方具有这样的逻辑。经典的建议是将此代码移动到模型中，但不久之后，您的模型就会因愚蠢的一次性辅助方法而变得臃肿。解决方案：模式演示者。

我不明白第二种情况。

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

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

主要问题是 - Presenter 模式对控制器测试有什么好处？

4

2 回答 2

0

我看过 Jay Fields 关于 Rails Presenter Pattern 的演示，我发现他的例子很有用，我还没有真正看过第三方的其他作品，尤其是关于导体的作品。

对我来说，优点是模型解耦，即与控制器和其他模型完全隔离。我认为这是处理业务逻辑的更好方法，因此控制器可以保持精简，并且对底层数据存储及其结构一无所知。然而，最初的 Rails Presenter Pattern 有一个问题，它包含很多问题。Presenter 对象只是为了呈现数据，它应该位于控制器和视图之间，这就是为什么导体应该受到额外关注，因为它们位于模型和控制器之间。

正如 Enterprise Rails 和全面的领域驱动设计一书中提到的那样，还有一些逻辑和物理模型可供选择。

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

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

于 2011-07-26T18:49:26.303 回答
0

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

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

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

另一方面，如果将对象传递给视图，它看起来就像一个没有做太多事情的演示者。也许只是一些前瞻性思维来管理未来的复杂性。

于 2012-02-17T21:10:18.540 回答