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

[Enrico Teotti]

@Jhon

1) Why is it ok to end up with a directories for Controllers, Views and
Helpers?

I say it's ok only because the framework sets that as a convention. If you
use those conventional directories in different contexts namespacing and
gems are necessary.

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?

Sometime the classname has that suffix ie. ValidReservationPresenter.



@mark

As application complexity grow moving away from AR conventions
(ie. validation and relationships) is a must. I like your db namespace
approach, sometime I think of AR as a repository so you could use that
keyword.

> gradually introduce this kind of structure as appropriate.

Agreed that on a small app this approach can be unnecessary, but I've
rarely seen an app staying small so knowing when to introduce is very
important. I hope my article gave that insight.


On Wed, Sep 9, 2015 at 5:20 AM, Mark Burns <markthedeveloper at gmail.com
<javascript:;>> wrote:
> 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.
>
> 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, 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 <javascript:;>> 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
<javascript:;>>
>> 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 <javascript:;>
>>> 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 <javascript:;>
>> 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 <javascript:;>
> 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
>



--
[skype] enrico.teotti
[web] http://teotti.com
[twitter] agenteo


-- 
[skype] enrico.teotti
[web] http://teotti.com
[twitter] agenteo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20150910/b18cc0bd/attachment-0003.html>