[LRUG] Hexagonal Architecture Guidelines For Rails
Stephen Best
bestie at gmail.com
Tue Mar 18 11:16:17 PDT 2014
Sorry Mike I hadn't seen your post, I think you explained it pretty well.
On 18 March 2014 17:10, Mike Kelly <mikekelly321 at gmail.com> wrote:
>
>
>
> On Tue, Mar 18, 2014 at 4:48 PM, Andrew Premdas <apremdas at gmail.com>wrote:
>
>> 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.
>>
>
> There are a couple of problems here. In general, if your app is complex
> enough that rails conventions are becoming painful it seems more likely
> that mutative actions may have more than just success/fail outcomes. Also,
> by rails conventions, public methods on a controller are assumed to be
> routable-to actions - any callback methods you put on your controllers will
> defy this convention. You will probably need to introduce some kind of
> grouping convention for the callbacks to a given action. There is also the
> issue of collisions in the names of the callbacks, which will force you to
> prefix them with the action name i.e. `update_success` instead of just
> `success`.
>
> Btw, I'm not advocating for the style here - I'm just sharing my
> experience having applied it.
>
> Cheers,
> M
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140318/4c245532/attachment-0003.html>
More information about the Chat
mailing list