Como o Rails fornece estrutura em termos de MVC, é natural acabar usando apenas o modelo, a exibição e os contêineres de controlador que são fornecidos para você. O idioma típico para iniciantes (e até alguns programadores intermediários) é incluir toda a lógica do aplicativo no modelo (classe de banco de dados), controlador ou exibição.
Em algum momento, alguém aponta o paradigma "modelo gordo, controlador fino" e os desenvolvedores intermediários rapidamente tiram tudo de seus controladores e jogam no modelo, que começa a se tornar uma nova lixeira para a lógica de aplicativos.
Controladores magros são, de fato, uma boa idéia, mas o corolário - colocar tudo no modelo, não é realmente o melhor plano.
No Ruby, você tem algumas boas opções para tornar as coisas mais modulares. Uma resposta bastante popular é usar apenas módulos (geralmente escondidos lib
) que contêm grupos de métodos e depois incluí-los nas classes apropriadas. Isso ajuda nos casos em que você tem categorias de funcionalidade que deseja reutilizar em várias classes, mas onde a funcionalidade ainda está nocionalmente anexada às classes.
Lembre-se, quando você incluir um módulo em uma classe, os métodos tornam-se métodos de instância da classe, para que você ainda acabar com uma classe que contém uma tonelada de métodos, eles estão apenas organizou muito bem em vários arquivos.
Essa solução pode funcionar bem em alguns casos - em outros casos, você vai querer pensar em usar classes em seu código que não sejam modelos, visualizações ou controladores.
Uma boa maneira de pensar sobre isso é o "princípio de responsabilidade única", que diz que uma classe deve ser responsável por um único (ou pequeno número) de coisas. Seus modelos são responsáveis pela persistência de dados do seu aplicativo no banco de dados. Seus controladores são responsáveis por receber uma solicitação e retornar uma resposta viável.
Se você tem conceitos que não se encaixam perfeitamente em essas caixas (persistência, pedido / resposta de gestão), você provavelmente vai querer pensar sobre como você seria modelar a idéia em questão. Você pode armazenar classes não modelo em app / classes ou em qualquer outro lugar e adicionar esse diretório ao seu caminho de carregamento, fazendo:
config.load_paths << File.join(Rails.root, "app", "classes")
Se você estiver usando passageiro ou JRuby, provavelmente também desejará adicionar seu caminho aos caminhos de carga ansiosos:
config.eager_load_paths << File.join(Rails.root, "app", "classes")
O ponto principal é que, quando você chega a um ponto no Rails em que se pergunta: é hora de reforçar seus chops Ruby e começar a modelar classes que não são apenas as classes MVC que o Rails fornece por padrão.
Atualização: Esta resposta se aplica ao Rails 2.xe superior.