Aplicações Rails

Agora que o Rails está pronto para trabalhar, vamos estudar a estrutura básica de uma aplicação Rails.

Antes de mais nada, você precisa aprender a CRIAR uma aplicação Rails.

Abra seu prompt de comando (se for usuário de Windows) ou terminal (se for usuário de Linux) e digite:

rails site

Isso vai criar toda a estrutura básica da sua aplicação. O primeiro parâmetro apenas avisa que o que você quer é criar uma aplicação Rails. O segundo diz o nome da aplicação.

Agora que a estrutura está criada, vou explicar alguns conceitos para que você possa entender o que significa cada uma das pastas. Certos conceitos, como bancos de dados, deveriam ser conhecidos antes de você querer se aprofundar em desenvolvimento web, então não vou me aprofundar neles. Mas existem princípios que não são amplamente conhecidos, como os já citados DRY e REST.

Antes de mais nada, vamos ter consciência do que é MVC. É um padrão de arquitetura que tenta dividir as responsabilidades da aplicação em três divisões: uma delas se encarregará dos dados (Model, ou Modelo); a outra do layout e apresentação (View, ou Visualização) e o último serve de "cola" entre os dois, processando eventos e entradas de usuário, enviando-os para modelos, ou pegando os dados do modelo e aplicando-os às visualizações (o Controller, ou Controlador).

MVC é a base do Rails. Todo o framework foi projetado e construído pensando em torná-lo o mais compatível possível com este padrão. E o melhor de tudo: conseguiu. Vamos ver como logo, logo.

O DRY (Seco) é outro elemento importantíssimo para o Rails, e significa algo tão simples quanto o que o nome indica: Don't Repeat Yourself (Não Repita a Si Mesmo). Como ficaria muito estranho chamá-lo de NRaSM, continuemos chamando de DRY. O que o DRY quer dizer é que você deve, ao máximo, evitar fazer o mesmo código duas ou mais vezes, o que torna a manutenção do site muito mais fácil, já que você não vai precisar se preocupar em esquecer de alterar um código duplicado.

Isso é quase sempre possível. Quase porque o sistema de herança do Rails não é tão bom, então se você tiver um sistema com dois tipos de usuário, digamos, Professor e Aluno, você vai precisar fazer o mesmo código de autenticação para ambos. É algo que considero um defeito do Rails e espero que seja corrigido em versões futuras.

Se eu estiver errado e houver uma forma de fazer isso, por favor, avisem-me.

E, finalmente, o REST, o conceito mais complicado dos três. Representational State Transfer (Transferência de Estado Representacional) se refere a um conjunto de recursos (geralmente, páginas HTML, mas pode ser RSS, XML, imagens, ou qualquer outra coisa que vier à sua cabeça) onde realizamos ações CRUD (Create, Read, Update, Destroy; ou Criar, Ler, Atualizar e Destruir). No fim das contas, todas as ações em uma aplicação de banco de dados podem se resumir a essas, por isso REST é tão útil em Rails (que é um framework web para aplicações focadas em bancos de dados, afinal).

Com esses conceitos explicados, vamos à aplicação.

Abrindo o diretório da sua aplicação, você verá essas pastas:

Explicarei o que cada uma significa.

• app armazena tudo diretamente relacionado à aplicação. Ou seja: os Modelos, as Visualizações e os Controladores (entendeu agora? Hã? Hã?). Se você abri-la, você verá uma pasta para cada uma dessas divisões e uma pasta helper. Esta pasta serve apenas para armazenar funções que puderem ser usadas em qualquer parte da aplicação. Não se preocupe muito com ela.
• config armazena dados sobre a inicialização da aplicação (boot.rb), sobre o gerenciador de banco de dados usado (database.yml), sobre os ambientes de desenvolvimento (environment.rb) e sobre as rotas (routes.rb). Não se preocupem com nada disso, explicarei em posts futuros.
• db armazena tudo o que está relacionado ao banco de dados. Também explicarei como mais tarde.
• doc armazena a documentação gerada com o comando rake doc:app. Também explicarei mais tarde.
• lib armazena qualquer módulo do Ruby que você queira usar na sua aplicação.
• log armazena o log do servidor. Simples assim.
• public armazena todas as informações estáticas da aplicação, incluindo HTML estática, CSS, imagens e Javascript.
• script armazena os scripts utilitários do Rails, como um script para rodar o servidor e outro para criar um novo modelo ou um novo controlador. Explicarei mais tarde (sim, eu sei que tô deixando muita coisa para mais tarde, mas o post JÁ ESTÁ grande assim).
• test armazena os testes de unidades que serão usados na aplicação. Muito útil para quem se utiliza de desenvolvimento ágil. Adivinha só? Vou explicar mais tarde.
• tmp armazena o cache e as sessões da aplicação.
• vendor armazena quaisquer plugins instalados.

Como podem ver, o Rails organiza ao máximo sua aplicação. Imagine-se programando numa aplicação ASP: você mesmo teria que criar as pastas e os arquivos, e geralmente o faria de forma caótica. Depois de um tempo, você já não saberia mais encontrar o que quer que seja na aplicação.

Com Rails, como você pode ver, encontrar tudo fica mais fácil. Especialmente quando ele tem um utilitário para gerar a documentação.

Isso é tudo por hoje. No próximo post, explicarei scaffold.