[LRUG] [Blog post] (Rails) Application directories named as architectural patterns antipattern

[Mark Burns]

This is an approach that has worked well for me on a couple of projects.
I think I gave up on fighting rails about where to put the views and the
controllers, and had a mix of approaches. I.e. only moving towards this
approach for the obvious cases.
Where there is a clear grouping of a large enough bunch of related items
e.g. DictionaryEntry, DictionaryEntryPresenter, DictionaryEntryCreation,
etc. then it makes it easier to navigate and fits in well with the concept
of connaissance <https://www.youtube.com/watch?v=HQXVKHoUQxY>.

It does lend well to namespacing, which then leads nicely into separating
into engines. And in one case, for an unused area of functionality it was a
surprising case of
rm -rf dictionary_entry specs/dictionary_entry

Run the specs and everything still works. Feature removed! *(Then just
quietly remove the views and controllers/routes afterwards). *

Didn't have time to look into getting that aspect smoothly done. But I
would probably better spend that time looking at trailblazer
<https://github.com/apotonick/trailblazer>, which seems to have a lot of
great concepts in it.

Along these lines, I quite enjoy the concept of keeping the spec close to
the implementation as golang does. I've only gone as far as domain concept
based folders in the spec folder as mentioned. I'd be interested to hear if
anyone has had success with a directory listing that looks like this:

dictionary_entry.rb
dictionary_entry_spec.rb


The only fiddly issue apart from the views/controllers folders was with AR
and namespacing based on the domain concept. Which would traditionally be
the ActiveRecord model name.
E.g. rather than pollute a DictionaryEntry AR model with tons of classes, I
ended up namespacing all my AR models as Db::DictionaryEntry etc.
Which when you have lots of objects in an app serves a dual purpose of
hinting which one is the thing that writes to the db. Probably a
double-edged sword, hungarian notation anybody?

But equally, on a small app, with a few presenters, a few controllers and
non-obvious groupings then it is overkill. It doesn't really cost much more
to gradually introduce this kind of structure as appropriate.

On Wed, Sep 9, 2015 at 5:59 PM <jc at panagile.com> wrote:

> Hi Enrico,
>
> Thanks for sharing this. It’s an approach that I agree with in general -
> I’d much rather classes were grouped by domain than by pattern. I have got
> a couple of questions though:
>
> 1) Why is it ok to end up with a directories for Controllers, Views and
> Helpers?
>
> 2) Sometimes you are creating classes that fulfil specific roles within
> the framework; e.g, Presenters. How do identify their function when they
> aren’t grouped in a directory?
>
> (Or maybe my assumtion at the start of the second question is wrong, in
> which case I’d like to hear why.)
>
> Thanks,
> John
>
>
>
> On Tue, Sep 8, 2015 at 5:43 PM, Enrico Teotti <enrico.teotti at gmail.com>
> wrote:
>
>> Hi,
>>
>> I wrote a blog post on (Rails) application directories named as
>> architectural patterns and suggesting a more intention revealing
>> alternative:
>>
>>
>> http://teotti.com/application-directories-named-as-architectural-patterns-antipattern/
>>
>> Ciao,
>>
>> Enrico
>>
>> --
>> [skype] enrico.teotti
>> [web] http://teotti.com
>> [twitter] agenteo
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
>> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
>> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: 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/20150909/3900840a/attachment-0003.html>