Antecedentes: existem vários locais em nosso aplicativo em que queremos exibir informações orientadas a datas em um calendário. A gema event_calendar parece legal e tem muitos comentários, por isso é o que estou planejando usar. No entanto, ele foi projetado para funcionar com um modelo. Não atualizarei nossos modelos existentes para atender às suas necessidades, portanto criaremos uma classe DTO e uma função auxiliar para construir uma matriz de instâncias de nossos modelos existentes.
Minha pergunta é: onde essa classe DTO deve viver? Parece que deve ser definido dentro de ViewHelper , mas isso violará DRY assim que eu usar o calendário para dois modelos (nota: as funções auxiliares serão diferentes, é apenas a classe DTO que permanecerá a mesma).
Então, existe um lugar padrão na árvore de diretórios do Rails onde classes não-relacionadas a modelos vivem?
Ou há uma maneira melhor / mais idiomática de fazer isso? Um pensamento que tive foi fazer com que minha função de ajuda decorasse as instâncias do modelo existente com os métodos que o event_calendar quer ver.
Acho que o equivalente do Objeto de Transferência de Dados que você mencionou é chamado de apresentador no ecossistema do Rails.
Em projetos com poucos apresentadores, eu os vi no diretório /lib , mas você também pode criar um diretório /app/presenters .
Confira também esta postagem do blog sobre apresentadores de Steve Klabnik.
Acabei criando uma classe base em lib , que define os atributos e alguns métodos auxiliares. Eu mantive uma classe dentro do helper, mas tudo o que tem é um initialize (é aí que as coisas interessantes acontecem). Eu também tenho uma função auxiliar que faz o map para converter objetos.
Ao ler o blog de Steve Klabnik, me deparei com a seguinte citação, que, em minha opinião, resumiu meus sentimentos. Eu acho que superei isso.
Maybe it's that lib/ feels like such a junk drawer
Se você achar que está se repetindo muito, talvez queira dar uma olhada na gem das células . As células são basicamente mini-controladores que são especialmente úteis ao criar widgets e afins.
O readme resume bem:
Say you’re writing a Rails online shop - the shopping cart is reappearing again and again in every view. You’re thinking about a clean solution for that part. A mixture of controller code, before-filters, partials and helpers?
No. That sucks. Take Cells.
Tags design ruby-on-rails