Estrutura da Aplicação

De Wiki Expresso V3
Ir para: navegação, pesquisa

Conteúdo

Padrão de aplicação de Tine 2.0

O padrão de aplicação PHP 2.0 Tine é fácil de entender. Você já pode ter usado o padrão de projeto MVC que é semelhante, mas não idêntico ao padrão utilizado para aplicações Tine 2.0.

Fizemos apenas uma pequena extensão para o padrão MVC padrão para se adequar à situação especial Tine 2.0 tem, que são explicadas como se segue.

Alterações na versão 2008/12

Mais de um controlador (você pode usar um para cada modelo) / novo diretório Controlador

  • Novo diretório Frontend
  • Novo diretório Servidor
  • Nova inicialização Tinebase
  • Novas classes abstratas Frontend / Controller / backend que devem ser estendidos pelas classes de aplicativos
  • novo diretório exceção (ver: Exceções)

Aplicação de Página Única

Tine 2.0 é um aplicativo de Página Única chamada (SPA). Isto significa que qualquer coisa é servido a partir de um único URL, o index.php. Se uma tela de login é mostrada ou se um aplicativo faz uma operação transacional complexo, é sempre tratado pelo index.php.

Esta disposição simplifica o fluxo da aplicação dramaticamente, como não há necessidade de descobrir os controladores / ações exigidas pelo url e não há necessidade de definir regras de reescrita. Como consequência, não use um controlador de frente tradicional e só tem um distribuidor de peso-leve no index.php.

Arquitetura Orientada a Serviços

Tine 2.0 tem uma arquitetura orientada para serviço. As vistas normais em aplicações MVC são perfeitamente conveniente para a saída HTML. No entanto, o servidor Tine 2.0 retorna quase sem HTML, mas é capaz de servir os dados necessários em várias representações. Além disso, também recebe suas ações e dados também através de várias representações.

Como consequências aplicações Tine 2,0 normalmente não têm pontos de vista, mas eles têm aulas fontend, por exemplo, uma classe JSON. Estes aulas frontend lidar com todas as conversões de entrada e saída de e para o formato solicitado, por exemplo, JSON.

Suporte a Múltiplos Backends

O padrão de aplicativo 2.0 Tine é projetado para suportar vários backends. Isto significa que o armazenamento de registos de aplicações pode consistir totalmente de diferentes tipos. Um exemplo simples é a lista de endereços. É contatos podem ser obtidos a partir de um SQL backend ou de um LDAP backend.

No padrão MVC padrão dos modelos fazer as operações de persistência em uma única instância de persistência, o que significa que normalmente eles fazem todo o manuseio de banco de dados SQL. Isso não se encaixa no Tine 2.0 de múltipla exigência back-end.

Como consequência, os modelos Tine 2.0 são apenas recipientes de dados simples e não tem nada a ver com a persistência. A loja controladores e obter esses modelos simples via as classes back-end que escondem a complexidade dos diferentes back-ends físicas através da implementação de uma interface pública simples.

Banco de Dados de Exemplo: Music

Vamos desenhar os diagramas UML de um banco de dados de simples para música. O banco de dados de áudio é um arquivo XML iTunes por um lado, e um banco de dados SQL de MythTV, por outro lado. Para o momento nós só acessar o banco de dados por nossa interface web, por isso, só precisa de um frontend JSON. O coração da aplicação é o controlador. É onde toda a lógica de domínio e verificações de ACL são feito. Nota do modelo que é passado através de todas as instâncias.

Um pedido de gravação a partir do cliente é seguido por um novo álbum. O Zend_Json_Server mãos uma matriz para o Music_Json. Ela cria uma ficha Music_Model_Album e faz todas as conversões necessárias na estrutura de dados. Além disso, a interface Json decide se a ação de criar ou atualizar o controlador está a ser utilizado.

O controlador verifica ACL, faz o registro de histórico, marcação e as relações e todas as outras lógicas de domínio. Ele decide que back-end está no comando e as mãos sobre o registro para o back-end.

O backend lida com toda a complexidade do armazenamento físico e retorna um novo recorde do álbum salvo.

Convenções de Nomeação

Nomes de Arquivo de Classe=

Music/ 
Music/Controller.php
Music/Exception.php
Music/Frontend/Json.php
Music/Frontend/Http.php
Music/Controller/Album.php
Music/Model/
Music/Model/Album.php
Music/Backend/
Music/Backend/Album/iTunes.php
Music/Backend/Album/mythTV.php
Music/Exception/AccessDenied.php
Music/Exception/InvalidArgument.php
[…]

Nomes de Função

Cada modelo corresponde a um ou mais backends. Os nomes das funções no frontend e controlador deve seguir uma rigorosa convenção de nomes.

save<Modelname> (creates or updates a single record)
get<Modelname> (gets a single (fully featured) record)
search<Modelname>s (searchs a set of (simple) records)
delete<Modelname>s (deletes a set of records identified by their ids)
update<Modelname>s (same updates one or more fileds in multiple records identified by their ids

Controlador

Para cada modelo de a aplicação não deve ser um controlador correspondente. Eles devem ser chamado assim: <ApplicationName>_Controller_<modelName>. Os nomes das funções devem ser assim:

getInstance
create
update
get
search
searchCount
delete

Essa convenção de nomenclatura (note o padrão Singleton) é importante para a funcionalidade da comunicação entre módulos.

Desenvolvimento

Ferramentas pessoais
Espaços nominais

Variantes
Ações
Navegação
Ferramentas