Perguntas frequentes

Esses frameworks impõem uma curva de aprendizado bastante árdua, obrigando a assimilar conceitos que lhes são próprios.

Você se torna então um desenvolvedor Symfony (ou outro), e não mais um “desenvolvedor PHP”.

E ao mesmo tempo, os conceitos simples que deveriam ser gerenciados pelo framework se tornam desnecessariamente complexos (tente criar plugins com o Symfony, você terá que desenvolver um event listener…).

Esses micro-frameworks podem parecer mais simples de implementar à primeira vista. Mas, ao misturar o roteamento e os controladores como fazem, eles tornam o código menos legível e, portanto, mais difícil de manter ao longo do tempo.

E para aqueles que são baseados em frameworks pesados (Symfony para o Silex, Laravel para o Lumen), o restante do seu código ainda sofre com a pesadez subjacente.

O Temma é usado em produção por empresas cujos servidores nem sempre conseguem acompanhar o ritmo de lançamento das versões do PHP.

Como consequência, optamos por permanecer compatíveis com a versão do PHP fornecida na penúltima versão LTS (suporte de longo prazo) da distribuição Linux Ubuntu.

Smarty é o padrão de fato dos motores de template em PHP.

Ele apresenta várias qualidades:

• Uma sintaxe simples e clara, facilmente assimilável por designers gráficos distantes da lógica de desenvolvimento.
• Possibilidades de extensão fáceis de implementar, com a criação de filtros em PHP.
• Desempenho que pode ser ajustado adicionando cache em fragmentos de templates.

Mesmo que a crítica ao Smarty pareça estar na moda entre alguns “pensadores” ativos na comunidade PHP (principalmente aqueles que acabam propondo clones do Smarty), não se pode questionar sua ampla adoção por uma maioria silenciosa dessa mesma comunidade.

Porque será mais eficiente usar o PhpMyAdmin, PhpPgAdmin, PhpRedisAdmin, Adminer…

Não é o papel de um framework oferecer esse tipo de funcionalidade. O papel de um framework é oferecer as bases técnicas que permitem desenvolver essas ferramentas.

Os motivos geralmente citados para o uso de um ORM são:

1. Não precisar escrever consultas SQL.
2. Manipular apenas objetos.
3. Poder trocar de banco de dados quando necessário.

Veja como o Temma responde a isso:

1. Para consultas em uma única tabela, os DAOs do Temma não exigem a escrita de consultas SQL. Para consultas mais complexas (junções, agrupamentos, ...), é sempre mais eficiente escrever as consultas "manualmente".

   Para contornar seus problemas de desempenho, os ORMs oferecem linguagens derivadas do SQL (HQL para o Hibernate, DQL para o Doctrine). Os desenvolvedores ainda precisam escrever suas consultas, exceto que elas são processadas por uma camada intermediária (com sua sintaxe específica e lentidão associada).

   Sejam quais forem os desenvolvimentos realizados, será preciso verificar no banco de dados se tudo está armazenado corretamente. E, portanto, será preciso digitar consultas SQL. Um desenvolvedor Web que não seja capaz de fazer isso logo terá problemas.

2. Se a vontade de manipular apenas objetos pode ser compreendida em certos ambientes, o "PHP way of life" se adapta muito bem à transferência de dados baseada em simples listas e arrays associativos. É a maneira mais flexível e rápida de estruturar seus desenvolvimentos em PHP.

   Aliás, é possível notar que mesmo os desenvolvedores que só querem manipular "entidades" (os objetos que representam os dados no banco) usam arrays associativos ao se conectar a APIs externas. No entanto, poder-se-ia argumentar que os dados deveriam sempre ser manipulados da mesma forma, independentemente de sua origem.

3. A verdadeira camada de abstração é constituída pelos DAOs. O código de negócio que os utiliza não precisa ser modificado, mesmo em caso de mudanças profundas que exijam alterar as consultas presentes nos DAOs.

Em vez de usar um ORM existente como o Doctrine ou se basear no padrão Active Record, o Temma utiliza o padrão Data Access Object (DAO, abreviado). Este é ao mesmo tempo mais eficiente em sua execução e mais simples de usar.

O uso dos DAOs é cristalino:

• Para recuperar os dados de um registro em uma tabela, chama-se um método do DAO. Obtém-se um array associativo, que oferece uma chave para cada campo da tabela.
• Quando recuperamos vários registros de uma tabela, obtemos uma lista de arrays associativos. Podemos iterar sobre ela com todas as funções nativas do PHP, como foreach. É simples, claro, eficiente.
• Ao evitar converter cada linha de resultado de uma consulta em objeto, evitamos consumir memória desnecessariamente e realizar processamentos adicionais.

Os atributos que têm um underscore no início do nome são criados automaticamente pelo Temma:

• $this->_session é criado pelo framework, exceto se a configuração desativar explicitamente as sessões.
• $this->_loader é sempre criado pelo framework, para gerenciar a injeção de dependências.

Em contrapartida, os atributos de acesso às fontes de dados têm o mesmo nome que foi definido na seção dataSources da configuração (veja a documentação).

Esses nomes dependem inteiramente da sua configuração. Por exemplo, a conexão com o banco de dados pode se chamar diferente de "db" (você pode escolher "database", "sql", "mysqlserver3", ou outro).
No entanto, note que o plugin de cache espera que a conexão com o cache se chame efetivamente "cache" e não outra coisa.

O componente de injeção de dependências do Temma funciona segundo um esquema bastante clássico. Em si, é semelhante a outros componentes como o PHP-DI (veja Understanding Dependency Injection), exceto que ele integra o tratamento de casos particulares próprios do Temma.

O componente do Temma pode ser usado como um Service locator ou fazendo autowiring. O uso típico é utilizar o service locator nos controladores e fazer autowiring com os objetos de negócio.
No entanto, é possível usar o service locator em todos os objetos de uma aplicação, o que traz certas vantagens (veja In Defense of Service Locator), ao custo de um acoplamento mais forte do código.