1Um comentário

• Eriksen Costa(usuário não autenticado)

  25 de Fevereiro de 2010, 16:51

   

  Charles,

  Eu tenho a sensação que foi usado um gerador de classe muito rústico, por isso temos tantas classes com estrutura semelhante mas sem hierarquias (classes abstratas ou implementação de interfaces).

  Não vou conseguir explicar aqui a API toda, mas ela está sendo desenvolvida em cima de alguns princípios simples e uma ressalva:

  Os componentes devem ser interdependentes com baixo acoplamento (namespace CoreExt)

  Os componentes não são de propósito geral. São desenvolvidos para serem usados no i-Educar (namespace Core)

  Desenvolver somente as features necessárias e somente quando necessário

  Esses princípios garantem que não será criado código desnecessário e que o foco do desenvolvimento é a necessidade de evolução. Mas todos eles se baseiam em uma ressalva: a não incorporação de um framework na base de código atual.

  Devido a complexidade do código existente e ao pouco conhecimento produzido pela comunidade, introduzir um framework poderia ter implicações na manutenibilidade e na evolução do sistema.

  Os diferentes frameworks PHP buscam ser soluções genéricas mas possuem convenções que criam vícios nos desenvolvedores mais básicos (aqueles que vão pouco além dos tutoriais de criação de blogs e de guestbooks). Poucos vão além da configuração ou das conveções padrão de seus frameworks. Prova disso é que muitos assumem os módulos de componentes MVC (como os do ZF e do symfony) como módulos de aplicação sem, no entanto, prover uma API de aplicação que possibilite que estes se tornem realmente plug-and-play.

  Decidi então que seria melhor desenvolver apenas o conjunto mínimo de features necessárias em forma de componentes reutilizáveis no contexto do i-Educar. Quando a comunidade estiver pronta para desenvolver do zero, então um framework será incorporado. Meu voto pessoal é bem público, já que tenho preferência ao Zend Framework (pela arquitetura) mas tenho como alternativa o symfony (pela elegância). Frameworks que dão suporte a PHP 4 ou que se baseiam no Joomla para alguma coisa estão longe de ter alguma simpatia minha. :-)

  É por isso que o MVC do i-Educar usa o design pattern Page Controller (CoreExt_Controller_Page) ao invés do Front Controller. Estudando a ordem em que as classes do sistema executam seus métodos para gerar uma tela da aplicação, vi que esse design pattern era o mais rápido para aplicar.

  Esse array $coreExt foi criado quando CoreExt_Config fora desenvolvido. Um Registry pode ser implementado. De fato, CoreExt_Singleton e CoreExt_Entity implementam-o implicitamente.

  Se observar melhor, verá que só usei globals em Core_View, CoreExt_Controller_Dispatcher_Strategy_PageStrategy e nos arquivos da aplicação em intranet/ (onde o uso de globals é descontrolado).

  Se quiser entender melhor como as classes funcionam, sugiro ler o testes (tests/unit/CoreExt e tests/unit/Core) e os módulos em modules/. Os docblocks contém também bastante informação. Você pode extrair uma boa API desses componentes usando o phpDocumentor ou o Doxygen (que gera ótimos diagramas de classe).

  att,
  Eriksen Costa
  Analista Desenvolvedor
  Projeto i-Educar, contribuições
  Cobra Tecnologia S.A.