Presenter 模式对于控制器测试的好处
我正在参与一个项目，该项目广泛使用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模式，单元格插件并且仅同意第一种情况：
您认为有一些逻辑，它广泛使用您的模型。其他观点中没有地方有这样的逻辑。经典的建议是将此代码移至模型中，但不久之后，您的模型就会因愚蠢的一次性辅助方法而变得臃肿。解决方案：模式 Presenter。
我不明白第二种情况。
您的构造函数包含大量代码，用于从数据库或其他存储中检索视图的某些值。你有很多fragment_exist吗？调用以确保当相应的片段已在缓存中时不会加载任何数据。由于特定动作的大小，测试它确实很困难。解决方案：模式 Presenter。
同样，在控制器测试中，我们仅检查实例变量。它们在这里的意思
主要问题是 - Presenter 模式对于控制器测试有什么好处？
I'm participating in a project, which extersively uses Presenter pattern.
I don't see a benefits of it, because all the methods of Presenter class are trivial, like this:
class Checkout::NewPresenter
def initialize(customer, order)
@customer, @order = customer, order
end
def customer
@customer
end
def order
@order
end
end
Guys are talking to me, that this pattern makes testing of controllers more simpler. We are abstracted from controller's logic and need just to test presenter object on certain return values.
But, this effect can be achieved with examining instance variables of controller, without any presenter layer.
I've ready Simplifying your Ruby on Rails code: Presenter pattern, cells plugin and agree only with first case:
You have some logic in your view, which uses your models extensively. There are no places in other views with such logic. The classic recommendation is to move this code into a model, but after a short time your models become bloated with stupid one-off helper methods. The solution: pattern Presenter.
I don't understood second case.
Your constructor contains a lot of code to retrieve some values for your views from the database or another storage. You have a lot of fragment_exist? calls to ensure no of your data is loaded when corresponding fragment is already in cache. It’s really hard to test a particular action because of it’s size. The solution: pattern Presenter.
Again, in controllers testing, we are examining only instance variables. What they mean here
The main question is - what benefits has Presenter pattern for controllers testing ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我看过 Jay Fields 关于 Rails Presenter Pattern 的演示，我发现他的示例很有用，我还没有真正看过第三方的其他作品，尤其是围绕 Conductors 的作品。
对我来说，优点是模型解耦，即与控制器和其他模型完全隔离。我认为这是处理业务逻辑的更好方法，因此控制器保持精简并且对底层数据存储及其结构一无所知。然而，最初的 Rails Presenter 模式有一个问题太多。演示者对象只是为了呈现数据，它应该位于控制器和视图之间，这就是为什么 Conductor 应该引起额外的兴趣，因为它们位于模型和控制器之间。
正如 Enterprise Rails 和全面的领域驱动设计一书中提到的，还有一些替代的逻辑和物理模型。
当然，Rails 世界中当前的解决方案是为模型创建方法来操作关联模型，并将所有业务登录信息填充到其中。
对于 DDD，我已经看到了一些关于 Rails 的幻灯片和建议，但似乎还没有一个完整的实现，我希望带有生成器的 gem 在不久的将来将变得可用。 DDD 对于复杂的项目来说是一个有用的选择，不仅如此，而且作为设计的替代方法，rails 意味着灵活，允许删除代码和模块化扩展，因此我不认为将额外的层和类类型放入混合中问题。 Rails 纯粹主义者可能讨厌这个想法，但他们不需要使用它。
I have looked at Jay Fields presentations on the Rails Presenter Pattern I found his examples useful, I haven't really looked at other works from third parties especially around Conductors.
To me the advantage is to decouple the models, that is, total isolation from the controllers and other models. I think its a better way to deal with business logic and so that the controller stays thin and knows nothing about the underlying data storage and its structure. However, the original Rails Presenter Pattern had one problem it contained to much. A presenter object is just that to present data it should sit between controllers and views that's why Conductors should be additional interest because they sit between models and controllers.
There are also some alternatives out there logical and physical models as mentioned in the book Enterprise Rails and full blow domain driven design.
Of course, the current solution in the rails world is create methods for models that manipulate associated models stuffing all the business login into them.
With DDD I have seen some slides and proposals for rails but haven't seem a full blown implementation I hope a gem with generators will become available in the not so distant future. DDD would be a useful option for complex projects, not only that but as a alternative method of design and rails is meant to be flexible allowing drop in code and modular expansion so I don't see dropping extra layers and class types into the mix an issue. Rails purists may hate it the idea but they needn't use it.
您的示例看起来不像典型的演示者。演示者通常会包装单个模型，添加额外的视图相关逻辑（例如格式化日期），就像您通常使用辅助方法所做的那样。
Checkout 对象的上下文是什么，它是传递给视图还是在控制器中使用？
如果它在控制器中用于进行两个模型之间的交互，那么它看起来有点像 数据上下文交互。
另一方面，如果对象被传递给视图，它看起来就像一个没有做太多事情的演示者。也许只是一点前瞻性思维来管理未来的复杂性。
Your example doesn't look like a typical presenter. A presenter normally wraps a single model adding additional view related logic (e.g formatting a date), such as you would normally do with a helper method.
What is the context of the Checkout object, is it passed to a view or used in a controller?
If its used in a controller to conduct the interactions between two models then it looks a little like an aspect of Data Context Interaction.
On the other hand if the object is passed to a view it looks like a presenter which doesn't do much. Maybe just a bit of forward thinking to manage future complexity.