Por que o Temma não é baseado na versão mais recente do PHP?
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.
Como funciona a injeção de dependências do Temma?
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.
Por que o Temma não oferece um ORM?
Os motivos geralmente citados para o uso de um ORM são:
- Não precisar escrever consultas SQL.
- Manipular apenas objetos.
- Poder trocar de banco de dados quando necessário.
Veja como o Temma responde a isso:
-
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.
-
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.
-
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.
Por que o Temma usa o Smarty como motor de templates?
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.
Por que o Temma não gera uma interface de administração do banco de dados?
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.
Por que alguns atributos dos controladores têm um underscore no início do nome, enquanto outros não?
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.
Em que a gestão de atributos do Temma é diferente?
Na maioria dos frameworks PHP, os atributos são passivos: eles descrevem uma intenção, mas é o núcleo do framework que os analisa e aplica a lógica correspondente.
O Temma fez uma escolha diferente: os atributos são objetos ativos.
Quando instanciados, eles podem usar diretamente a API do framework (resposta HTTP, view,
segurança, fluxo de execução, etc.) para modificar o comportamento da aplicação.
O framework não precisa conhecer todos os atributos com antecedência: ele fornece um contexto de execução, e são os atributos que aplicam sua lógica.
Esse modelo permite aos desenvolvedores:
- criar seus próprios atributos funcionais;
- estender o comportamento da aplicação sem modificar o núcleo do framework;
- construir plugins simples, locais e legíveis.
Um atributo que não é instanciado pelo Temma permanece totalmente inerte: portanto, não há efeitos colaterais ocultos.
O loader (componente de injeção de dependências) do Temma segue uma lógica de programação orientada a aspectos e de injeção de dependências orientada a aspectos: os atributos desempenham o papel de aspectos da aplicação, aplicados em pontos precisos do ciclo de execução.