[LRUG] Hexagonal Architecture Guidelines For Rails

[Andrew Premdas]

On 18 March 2014 15:50, Mike Kelly <mikekelly321 at gmail.com> wrote:
>
>
>
> On Tue, Mar 18, 2014 at 3:42 PM, Andrew Premdas <apremdas at gmail.com> wrote:
>>
>> Some questions/points:
>>
>> 1. Why can't the controllers be the RailsAdapter?
>
>
> The main reason I've found this doesn't work is because Rails controllers
> tend to be responsible for handling many different CRUD actions over a
> collection. If you're adhering to tell don't ask this leads to controllers
> that have a huge public interface, because they need to have a callback
> method for handling each potential outcome for every action. By breaking out
> the callback methods for each action into decorators, you avoid this problem
> and group each action's callbacks together.
>
> Cheers,
> M

Surely having actions with lots of potential outcomes is just poor
design anyhow. Rails is a RESTful web framework and controllers used
resftully will provide at most 8 methods to work with a particular
resource. Most of these methods should only have one outcome, index,
new, show, edit just show something (anything else is exceptional);
update, create, delete have two outcomes success:failure. If you
follow the anti-pattern of having one controller dealing with all the
actions to a collection/model you'll be abusing Rails even if you use
hexagonal rails.

Referring back to the article Bestie says

The mysterious rails_adapter will be a wrap the Rails controller
defining a narrow interface that your app will depend on.

Now it seems to me the problem with Rails has never been the width of
interface of controllers. Its all about the width of interface of
models exposed in controllers, which is a very different thing. So I'm
all for decorating/wrapping models in controllers, but I'm less
convinced about totally bypassing controllers. For example I don't
like having to manually render views when a controller does this
perfectly well.

Perhaps the following which shows a complete controller from a
production app, and the bestie alternative might illustrate the point.

class ClientDetailsController < ApplicationController
  def show
    @client = ClientDecorator.new(get_client)
  end
end

vs

class ClientDetailsController < ApplicationController
  def show
    app_of_client_details.show_client_details(rails_adapter)
  end
end

+ all the code to manually render the view


-- 
------------------------
Andrew Premdas
blog.andrew.premdas.org