Caio Moritz Ronchi

O último framework que pretendo analisar este ano é o Symfony. Há algumas razões para escolhê-lo:

1. É escrito em PHP (minha análise já inclui frameworks em Ruby e Python)
2. Não tenta ser uma versão PHP do Rails (não que isso fosse algo ruim)
3. Possui farta documentação (inclusive um livro em português, que divide sua atenção com outros frameworks PHP populares)
4. Possui um livro oficial já publicado (isso é uma vitória quando consideramos que há em torno de 50 frameworks PHP por aí)

Este artigo, diferente de outro em que comparei Rails e Django frente a frente, pretende ser mais “light”: aponta apenas as diferenças de abordagens entre Rails e Symfony, sem entrar em tantos detalhes. Dito isso podemos seguir em frente.

Instalação

A instalação do framework foi feita sem grandes problemas, seguindo o tutorial do Symfony Brasil para instalação no Ubuntu. Basicamente fazemos a instalação com auxílio do PEAR. Não conheço nada a respeito do projeto PEAR, mas para mim pareceu uma alternativa PHP ao RubyGems.

Rodando a primeira aplicação

Durante a instalação somos “convidados” a criar a nossa primeira aplicação. Após a instalação fica disponível o comando symfony, responsável por criar a estrutura básica de diretórios do projeto, como acontece com o Rails. Em seguida, somos também convidados a configurar nosso apache2.conf para rodar essa nossa aplicação… peraí, já estamos no Apache? Será que não existe, dentro do Symfony, um servidor web para desenvolvimento, que iniciamos com um comando apenas, ao estilo WEBrick, do Ruby, ou o servidor de desenvolvimento do Django?

Resolvi ir direto à fonte, o livro do Symfony, no capítulo 3, “Running Symfony”. A seção “Configuring the Web Server” vai pelo mesmo caminho: configuração do Apache. Isso me intimidou um pouco, pois tenho um histórico de surras memoráveis contra o Apache (horas a fio para configurar as regras mais simples). Decidi não rodar minha aplicação recém-criada para evitar muito estresse.

Decidi, então, conhecer o framework “de fora para dentro”: como são implementadas suas funções principais, tais como ORM, validações e TDD.

Mapeamento Objeto-Relacional

Da mesma forma como Rails e Django, o Symfony adota um Mapeamento Objeto-Relacional (ORM) como maneira de facilitar a programação de código orientado a objetos sobre bancos de dados relacionais.

O ORM do Symfony é delegado a uma biblioteca provida por terceiros (Propel), a qual é desenvolvida sobre uma biblioteca de abstração de banco de dados (Creole). Propel parece ser uma biblioteca madura e robusta, de acordo com as funcionalidades descritas no site do projeto.

A parte que mais me interessa no caso de ORM é a definição de relacionamentos entre as tabelas ou modelos. A abordagem da ActiveRecord, por exemplo, fez uso das facilidades de Ruby para metaprogramação, criando uma Linguagem de Domínio Específico (DSL) para definição de modelos e suas relações. Como a Propel se sai nessa tarefa?

Tanto as tabelas Propel quanto os relacionamentos entre essas são definidos por esquemas XML. Bom, lembro de ter lido uma vez, não lembro onde, que XML só podia ser considerada uma linguagem “peso leve” se comparada à Java, uma linguagem “peso pesado”. Por exemplo, na comunidade Ruby, sempre que possível, vejos os projetos utilizando YAML em detrimento de XML. Por que? Pois YAML é mais fácil de manter manualmente, por não ser baseada na “sintaxe do abre-e-fecha” do XML. “Ah, mas quem precisa manter XML manualmente se temos IDE enormes que fazem isso por nós?”. Ok, cada um na sua.

E não é que a comunidade Symfony também gosta de YAML? Quando trabalhando em um projeto Symfony você define seus modelos em YAML, e o framework se encarrega de traduzir suas definições para o formato XML do Propel. Isso é muito bom!

Embora eu não tenha encontrado esse fato na minha leitura rápida pela documentação, Elliot Smith alerta para o fato de que no Propel é necessário declarar 4 classes por tabela, o que achei bastante estranho.

Validações

Uma das diferenças entre Rails e Symfony é o local onde são declaradas as validações dos modelos. No Rails elas são declaradas dentro dos próprios modelos, como código Ruby. Já no Symfony são declaradas externamente, em arquivos YAML.

Controle da evolução do banco de dados

O controle de evolução do banco de dados, no Rails, é feito por meio de migrações. Com elas é possível escrever, em Ruby, operações de atualização do seu banco de dados e garantir a atualização dos sistemas em produção de forma (teoricamente) indolor.

Como isso é feito no Symfony? De acordo com o wiki do projeto esse suporte existe, mas não conta com abstração de SGBD. Ou seja: migrações à base de SQL puro, sendo, portanto, dependente do SGBD escolhido.

Para maiores informações confira o artigo “Migrations” no wiki do Symfony.

Agilidade no desenvolvimento

Uma das coisas que torna ao menos o meu desenvolvimento ágil é o IRB do Rails. Com ele posso interagir com os meus modelos, testar minhas validações quando nada parece fazer sentido etc. Com o Django também é possível utilizar o shell interativo para interagir com os modelos. Mas e no Symfony, como fica? Acredito que não seja possível simular algo tão poderoso, depois de ter procurado sobre o assunto no Google. Isso é uma desvantagem grande.

Como não tive uma experiência real de desenvolvimento, recomendo que você confira o artigo do Elliot Smith sobre o desenvolvimento de uma pequena “blog engine” no Symfony.

Testes de software

O Symfony trabalha com um framework embutido para testes, chamado Lime. Eu não sou experiente em testes de software, e menos ainda com testes para código PHP. Mesmo assim foi possível compreender, pela documentação do capítulo 15 do livro do Symfony, que se trata de um framework completo: há testes para modelos, para controllers e para views, incluindo os testes com suporte a seletores CSS (que testam, por exemplo, se os elementos HTML que esperamos fazem parte do documento que retorna como resposta a uma determinada requisição HTTP).

Algo que chama a atenção é que, diferentemente dos frameworks xUnit, os testes do Lime não são cercados por uma classe. Os testes são executados no escopo global, após a inclusão (require) de alguns scripts. Acabei sem entender como o framework lida com a ausência dos métodos setup e tear_down. Para separar melhor a finalidade de cada teste o Lime usa e abusa da separação dos testes por diversos arquivos.

Links relacionados

• Symfony
• Symfony Brasil
• The Definitive Guide to Symfony
• The Definitive Guide to Symfony - Chapter 15 - Unit and Functional Testing
• I Hear a Symfony: Rails vs. the Symfony PHP framework