Benefits of Presenter pattern for controller testing

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 oth开发者_高级运维er 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 ?

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.

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.