Multi-Nível em PHP..the caminho certo?

Question

Eu tenho uma pergunta específica, que poderia usar uma resposta geral ... Ao construir aplicações multi-tier em PHP, que tudo tem que ser feito na camada de lógica de negócios, ou qualquer camada pode fazer o trabalho ... Exemplo, Vamos dizer que eu estou construindo um aplicativo que mostra informações de usuário (a partir do banco de dados) sobre a camada de apresentação. Devo usar a camada de negócios para simplesmente passar os dados para a camada de apresentação, ou apenas obter as informações do banco de dados diretamente dentro da camada de apresentação. Caso a camada de apresentação ser usado APENAS para apresentar os dados, a camada de acessor usados ??apenas para obter os dados, e todo o trabalho ser feito na camada de negócios?

Além disso, falando das diferentes camadas, é melhor fazer as coisas processualmente, ou usando OOP (como usar inclui para mostrar os modelos vs usando uma classe para incluir os modelos, validação de dados processualmente vs usando uma classe ou funções vs aulas para obter os dados do banco de dados, etc.)

Como você pode ver, eu estou tentando entender como as coisas funcionam, e a melhor maneira de fazer as coisas. Dito isto, se você tem algum conselho, ou qualquer dicas gerais sobre o assunto ... por favor deixá-los ..

Graças

Answer 1

aplicações Web e N-tier é interessante, principalmente porque a noção de N-tier se expandiu com a adopção generalizada de JSON e AJAX ou Flash e XMLRPC. Este href="http://www.webopedia.com/quick_ref/app.arch.asp" rel="nofollow noreferrer"> gráfico exibe uma escalonada linha azul que expressa bem isso. Para resumir: a lógica de negócios, acessor, e apresentação não só poderia existir no servidor - mas em alguns casos, mesmo no browser. A intenção do N-tier, no entanto, é separability . Se você precisa mudar a sua interface do usuário ou seu banco de dados, ou adicionar outras interfaces, você não deve estar afetando sua lógica de negócio. E isso é o que determinaria a sua API -. Antecipando o dia o seu HTML e CSS são descartados para o Flex e MySQL é trocado para Oracle

Esta é requisitos determinados, e em algumas aplicações web que eu usei, variações de N-tier são usados ??simultaneamente. Tomemos por exemplo LyrisHQ (um ASP e-mail). Eles têm uma aplicação web do cliente. Recentemente, eles olharam empurrando sua aplicação em Flash. Este é claramente o transporte de uma grande quantidade de dados certo para o navegador, e há provavelmente um pouco de lógica de negócios duplicados na interface do usuário do Flash. Devem manter ambas as aplicações, no entanto, uma vez que qualquer um é necessário para diferentes (e que se sobrepõem) requisitos.

A maioria das aplicações comuns do PHP não está considerando o transporte máximo de dados não formatados para o navegador. Mas se você fosse, isso iria informá-lo muito rapidamente como você gostaria de projetar suas APIs. Muito provavelmente, você iria querer controladores que poderiam falar XMLRPC, REST ou SOAP ... além de uma classe de controlador interno similar que seus modelos de apresentação PHP usado. Este seria estritamente significa para uma página de login web simples, você teria um modelo de PHP para o formulário de login que falava a uma classe LoginController. Uma interface XML seria igualmente usar a mesma classe LoginController. Assim como você diria que você seria maluco de escrever SQL em uma solicitação do Ajax ... você seria estritamente evitando escrever consultas em seus modelos de apresentação.

camadas de negócios podem ser mais ou menos rigoroso, porque muitas vezes nunca há uma exigência de marcas de comutação de banco de dados back-end. Em um projeto rigoroso N-tier, como seus objetos de negócios iria falar com seu banco de dados seria como se você pudesse mudar do MySQL para MS SQL sem reescrever a camada de negócios. Às vezes, isso é feito através da modelagem de objetos para cada tabela (Tabela gateway), cada linha (registro ativo), cada participar, ou cada transação. Este é o lugar onde algo como DOP ou PHP-ADO são úteis, mas insuficientes para completo isolamento. camadas ORM / Persistência em Java como Hibernate demonstrar melhor esse tipo de isolamento, muitas vezes, fornecendo um objeto Query Language (QVG).

Eu mesmo, eu estou atualmente a realizar uma transição back-end de uma aplicação PHP MySQL base até um um MS-SQL. A aplicação tem sempre apenas utilizado consultas SQL diretas. Imagine que escolher a forma de tomar uma série de consultas em uma classe e quer abstrair-los, ou subclasse, e esperemos que não alterar a lógica de negócios. No mínimo, você vai querer fazer todo o seu SQL chama indireta. ( S. O. post sobre PHP ORM .)

E, finalmente, à sua pergunta sobre OOP: usá-lo como você deve para cumprir suas exigências. Minha técnica pessoal é começar com certa lógica em um modelo de apresentação PHP por alguns minutos para fazer a bola rolar, muito em breve eu vou refatorar isso em uma classe e um modelo. Se eu tiver idéias comuns, eu quebrar rotinas em classes comuns, que se esforça para preservar o princípio de DNRY. (A SO post sobre isso aqui. OOP não é um requisito fundamental para o projeto N-tier. DNRY é muito importante para manter a sua fácil manutenção de código, tho. Ofprazos dez e âmbito-shift destruir uma API. Refatorar-lo até chegar o que você precisa para continuar. Aposto OOP vai ajudar a chegar lá.

Answer 2

Uma vez eu li algo dizendo que os grandes modelos (camada de negócios) deve ser preferido sobre grandes controladores (acessor Layer).

Além disso: É realmente depende do projeto. Em meus olhos nem sempre faz sentido usar OOP para tudo (provavelmente nem todos irão concordar aqui), especialmente em linguagens de scripting como PHP que muitas vezes é mais fácil simplesmente fazer validadores como funções ...

Answer 3

Eu definitivamente aconselho a não ter chamadas de banco de dados na camada de apresentação, que iria derrotar o seu propósito.

Existem diferentes abordagens para multi-tier arquitetura e eles têm diferentes recomendações.

Zend Framework que eu já trabalhei com é geralmente do formulário modelo Fat variante controlador / Fino.

Se encontrar este artigo Notas sobre a escolha de um Framework PHP para ser muito bom em comparação (neste caso) CakePHP para Zend Framework.

A maior diferença na minha opionion é a abordagem-over-configuração convenção tomada por CakePHP que é muito diferente do foco de configuração no Zend Framework.

Ao usar um quadro, que faz um monte de sentido se a implementação de uma arquitetura multi-tier, você está em uma forma forçada ou pelo menos empurrado para usar OOP, o que não é uma coisa ruim.

Você poderia naturalmente implementar, digamos, uma arquitetura de 3 camadas com chamadas funcionais puros, mas não escala muito bem com base na minha experiência.

Para um site do padrão MVC que na verdade é bastante diferente devido à forma como as camadas comunicar, é uma boa escolha.

A diferença entre um arco de 3-tier "normal" e o padrão MVC é que a vista tem acesso a tanto o controlador e a camada de modelo, enquanto que a camada de apresentação só tem acesso à camada lógica do 3-tier arco.

Answer 4

eu concordo com o que Franz disse, especialmente sobre preferindo modelos maiores sobre controladores maiores .. você também pode usar uma regra de ouro para ajudar a distinguir onde o código deve ir: se ele tem alguma coisa a ver com a estrutura UI / fluir, put -lo no controlador; se é a lógica de negócio puro, ele vai no modelo ..

vou acrescentar que, como um desenvolvedor Java que tinha muita experiência com Struts antes de testar as águas PHP, ele me levou um tempo para entender como aplicar ideias MVC para uma linguagem de script .. eu encontrei pessoalmente que o uso de um sistema como CodeIgnitor ajudou muito .. ele fornece a estrutura, bem como Struts, e incentiva bons padrões MVC ..

Answer 5

Os meus olhares mundo como este:

DB1 <- Model1 para fornecer acessor funções, a integridade dos dados, o negócio regras para esse conjunto de dados DB2 <- MODEL2 para proporcionar funções de assessor, dados integridade, regras de negócios para este conjunto de dados

Controlador: dados controla o fluxo para vistas, filtros / organiza os dados de Visualizações. regras Implementos de negócios para a aplicação dada . conhece o regras de negócio entre Models.

Visualizações: nada mais do que modelos que os dados de exibição fornecidos pela Controlador. Passar todos os dados para o controlador. Não tem conhecimento de Model1 ou Model2 ou o negócio lógica que governa-los.

Answer 6

Eu recomendo fazer alguma pesquisa sobre Design Patterns, pois esta é a peça que faltava do seu quebra-cabeça. Há uma série de livros específicos para PHP que cobrem este tópico (os de APress são bons), bem como a 'bíblia' de Design Patterns: noreferrer "design Patterns: Elements of Reusable Software Orientada a objetos"

Answer 7

Vamos esperar por mais versão estável do Doctrine2 .

Ele está sendo desenvolvido com a filosofia objeto de domínio persistência-ignorante. Será muito mais fácil desenvolver aplicações multi-tier com a ajuda deste quadro.