desafios na construção de -...

5

Desafios na construção de

um Framework de acesso a

dados em PHP

Dimas Ferreira Vidal

O presente artigo procura mostrar os principais desafios no processo

de desenvolvimento do framework PHPO2_DB de acesso a dados em

PHP, a partir das principais motivações que levaram ao seu

desenvolvimento. São apresentadas soluções de arquitetura e padrões

de projeto de software que foram utilizados, bem como uma

apresentação dos resultados obtidos neste processo, através da

descrição dos componentes e de suas funcionalidades.

O framework PHPO2_DB é um dos frameworks integrantes da

plataforma PHPO2 de desenvolvimento web, baseada em PHP,

projeto este apoiado pela Diretoria de Pesquisa Aplicada da

Universidade Estácio de Sá.

Palavras chaves: Framework, Proxy de acesso a dados, PHP, linguagem de programação. This article attempts to show the main challenges in PHPO2_DB

framework of the development process of data access in PHP, from the

main motivations that led to its development. Architecture solutions are

presented and software design patterns that were used as well as a

presentation of the results obtained in this process, through the

description of the components and their functionality.

The PHPO2_DB framework is one of the frameworks members of

PHPO2 web development platform based on PHP, this project

supported by the Applied Research Board of the University Estacio de

Sa.

Key words: Framework, Proxy data access, PHP programming

language.

6

O autor: Dimas Ferreira Vidal Economista pela UFRRJ e administrador pela UNESA, possui mestrado profissional em Administração e Desenvolvimento Empresarial pela UNESA, pós-graduação em Administração de Marketing e em Desenvolvimento de Sistemas Baseado em Objetos. Pesquisador e professor da Universidade Estácio de Sá, possui experiência em gestão financeira e no desenvolvimento de sistemas de informação de apoio a decisão empresarial.

Introdução

Diversos são os problemas envolvidos no desenvolvimento de sistemas orientado a objeto.

Alguns, no entanto, se destacam. O primeiro, e talvez o mais importante, está relacionado ao alto

nível de complexidade envolvida e a maneira de gerenciá-la. Em boa parte das vezes, a

modularização de um sistema permite dividir um sistema complexo em subsistemas mais simples e,

por conseguinte, mais fáceis de serem gerenciados. Dentre as diversas técnicas de modularização, a

separação da complexidade de um sistema em camadas foi a que mais se transformou em um

padrão de mercado. Para exemplificar o uso de camadas em um sistema, podemos destacar um dos

padrões mais utilizados para integração entre um sistema orientado a objetos e banco de dados

relacional. A figura 1 representa esta lógica.

Figura 1 – Representação do padrão de camadas

Fonte: Elaboração própria.

7

Esta questão nos leva ao segundo grande problema. O acoplamento necessário à integração

e dependência entre os diversos objetos e componentes de um sistema orientado a objetos. Se

considerarmos que o principio por trás do paradigma orientado a objetos é pensar em objetos ou em

componentes como uma representação máxima do padrão de camadas, nos faz pensar em objetos e

componentes de software o mais desacoplados possíveis um dos outros, permitindo com isso uma

maior independência, flexibilidade e reuso de seus recursos. Estas características são fundamentais

ao processo de desenvolvimento, de manutenção, de adição recursos necessários a novos requisitos

de sistema.

Isto nos leva ao terceiro grande problema. Como resolver a questão de dependência e

comunição entre os objetos e componentes de software? Como fazê-lo com o menor nível de

acoplamento possível?

Um framework tem como principal função implementar soluções para estes problemas,

tirando do desenvolvedor a responsabilidade de fazê-lo. Para tanto, um framework deve fornecer

uma arquitetura, funcionalidades e mecanismos de controle que permitam a solução de problemas

gerais ou específicos a que ele se destina. Isto nos leva a um dos principais conceitos que nos ajuda

a definir um framework, o conceito da inversão de controle. Ao desenvolver um sistema ou parte de

um sistema a partir de um framework, o que se espera é transferir o controle das soluções dos

problemas apresentados a ele. Isto permite ao desenvolvedor se dedicar às soluções dos problemas

de domínio do negócio ou do problema (ELLIOTT, O’BRIEN & FOWLER, 2009 ; FOWLER at.

al, 2008; HORSTMANN, 2007).

Padrões de Arquitetura e de Projeto no desenvolvimento de sistemas Orientado a Objetos.

Arquitetura em sistema de software não é um conceito fácil de ser definido e, por

conseguinte, não há unanimidade ao fazê-lo. De uma maneira em geral a arquitetura de um sistema

pode ser representada pela visão geral dos diversos recursos e componentes de um software e de

como eles se organizam. Um sistema pode apresentar diversas soluções em arquitetura, uma para

cada tipo de questão envolvida ou problemas para os quais são propostas soluções arquiteturais. No

entanto, é através da arquitetura que se pode ter uma compreensão geral de um sistema ou de como

ele será desenvolvido (FOWLER at. al., 2008).

Um padrão de arquitetura, assim como um padrão de projeto busca descrever um problema

geral ou específico de arquitetura ou de projeto que ocorre de forma sistemática para o qual é

proposta uma solução que possa ser aplicada todas as vezes que problemas de mesma natureza

surgirem (FOWLER at. al., 2008, GAMMA at. al., 2008).

8

Em geral, um padrão, seja de arquitetura, seja de projeto, é representado pelos seguintes elementos:

1: O nome do padrão – Trata-se de uma referencia que pode ser utilizada para descrever a

natureza do problema e a solução proposta.

2: A descrição do problema – Descreve o contexto do problema, seja ele um problema

geral ou específico.

3: A solução proposta – Descreve o conjunto de elementos que compõem a solução

proposta. De uma maneira em geral, as soluções propostas apresentam um arcabouço geral,

deixando a cargo do projetista as adequações específicas para um contexto específico.

4: Consequências – De uma maneira em geral, um padrão proposto apresenta um conjunto

de características positivas e negativas, vantagens e desvantagens de se aplicar a solução

proposta.

Dentre os diversos padrões de arquitetura já apresentados, destacam-se o “Padrão de

Arquitetura em Camadas”, dentre as quais as mais conhecidas são a “Arquitetura Cliente Servidor”,

“Arquitetura MVC – Model, View and Control”, e “Arquitetura de Mapeamento Objeto

Relacional”.

Seja qual for a arquitetura em camadas, seu principal objetivo será isolar em problemas

menores e mais fáceis de serem gerenciados um sistema complexo (FOWLER at. al., 2008).

Dentre os padrões de projeto, destacam-se os padrões desenvolvidos por Gamma, Helm, Johnson e

Vlissides (2008). Conhecidos como a Gang do Quatros. Estes autores descreveram 23 padrões

divididos três tipos de problemas para os quais propunham soluções. São eles Padrões de Criação de

Objetos, Padrões Estruturais, e Padrões Comportamentais. No Quadro 1 são apresentados os

padrões, bem como as descrições de seus propósitos.

Quadro 1 – Padrões de Projeto desenvolvidos pela Gang dos Quatro

Padrões de Criação

Abstract Factory: Fornecer uma interface para criação de famílias de objetos relacionados

ou independentes sem especificar suas classes concretas.

Builder: Separar a construção de um objeto complexo de sua representação, de modo que o

mesmo processo de construção possa criar diferentes representações.

Factory Method: Definir uma interface para criar um objeto, mas deixar as subclasses

decidirem qual classe a ser instanciada.

9

Prototype: Especificar os tipos de objetos a serem criados usando uma instância prototípica

e criar novos objetos copiando este protótipo.

Singleton: Garantir que uma classe tenha somente uma instância e fornecer um ponto global

de acesso a ela.

Padrões Estruturais

Adapter: Converter a interface de uma classe em outra interface esperada pelos clientes. O

Adapter permite que classes que tenham interfaces incompatíveis trabalhem em conjunto.

Bridge: Separar uma abstração de sua implementação, de modo que as duas possam variar

independentemente.

Composite: Compor objetos em estrutura de arvore para representar hierarquias do tipo

partes-todo. O composite permite que os clientes tratem objetos individuais e composição de

objetos de maneira uniforme.

Decorator: Atribuir responsabilidades adicionais a um objeto dinamicamente. Os decorators

fornecem uma alternativa flexível a subclasses para extensão da funcionalidade.

Facade: Fornecer uma interface unificada para um conjunto de interfaces em um

subsistema. O Facade define uma interface de nível mais alto que torna o subsistema mais

fácil de usar.

Flyweight: Usar compartilhamento para suportar grandes quantidades de objetos, de

granularidade fina fácil de usar.

Proxy: Fornecer um objeto representante, ou marcador de outro objeto, para controlar o

acesso ao mesmo.

Padrões Comportamentais

Chain of Responsibility: Evitar o acoplamento do remetente de uma solicitação ao seu

destino, dando a mais de um objeto a chance de tratar a solicitação.

Command: Encapsular uma solicitação como objeto, desta forma permitindo que você

parametrize clientes com diferentes solicitações, enfileire ou registre solicitações e suporte

operações que podem ser desfeitas.

Interpreter: Dada uma linguagem, define uma representação para sua gramática juntamente

com um interpretador.

Iterator: Fornecer uma maneira de acessar sequencialmente os elementos de um objeto

agregado sem expor sua representação subjacente.

Mediator: Definir um objeto que encapsula como um conjunto de objetos interage.

10

Memento: Sem violar o encapsulamento, captura e externaliza um estado interno de um

objeto, de modo que o mesmo possa posteriormente ser restaurado para este estado.

Observer: Define uma dependência um-para-muitos entre objetos, de modo que, quando um

objeto muda de estado, todos os seus dependentes são automaticamente notificados e

atualizados.

State: Permite que um objeto altere seu comportamento quando seu estado interno muda. O

objeto parecerá ter mudado sua classe.

Strategy: Define uma família de algoritmos, encapsula cada um deles e fazê-los

intercambiáveis. O Strategy permite que o algoritmo varie independente dos clientes que o

utilizam.

Template Method: Define o esqueleto de um algoritmo em uma operação, postergando a

definição em alguns passos para as subclasses.

Visitor: Representa uma operação a ser executada sobre os elementos da estrutura de um

objeto.

Fonte: Padrões de projeto da Gang dos Quatro (GAMMA at. al., 2008).

Motivações para o desenvolvimento de um framework em PHP

O PHP nasceu como uma linguagem de programação para a web. Suas características mais

relevantes são: simplicidade, código aberto, desenvolvimento colaborativo, integração ao servidor

web, dentre outras. Ao longo dos anos o PHP evoluiu e cresceu exponencialmente, muito devido a

contribuição de dezena de milhares de colaboradores em todas as partes do mundo, representando

hoje a maior infraestrutura de infraestrutura web disponível, particularmente com a combinação do

PHP, o servidor web Apache e o servidor de banco de dados MySql.

Esta evolução transformou o PHP em uma plataforma completa, flexível, com um volume

de recursos sem igual na indústria de desenvolvimento, disponível a qualquer desenvolvedor em

virtude de ter seu código fonte aberto. No entanto, este crescimento foi resultado de um

desenvolvimento descentralizado e em boa parte das vezes, sem fazer uso de padrões de projetos

maduros e disseminados no mercado.

Com relação aos recursos disponíveis pelo PHP para gerenciar acesso a banco de dados

relacional, estes sofrem as consequências deste processo. Apesar de poderosos e de uma diversidade

11

comparável às grandes plataformas de desenvolvimento, estas padecem da falta de uma interface

padrão, e em sua maioria se apresentam confusas.

Com a versão 5, foram introduzidos no PHP recursos mais maduros de Orientação a Objetos. Estes

novos recursos criaram a condição do surgimento de frameworks e ferramentas de abstração dos

diversos recursos disponíveis no PHP, fazendo uso das melhores práticas de desenvolvimento,

padrões de arquitetura e de projetos, minimizando assim os efeitos deste crescimento desordenado

(SOARES, 2013; DALL’OGLIO, 2013; DALL’OGLIO, 2009; NIEDERAUER, 2008).

PHPO2_DB – Framework de acesso a fonte de dados em Php.

O PhpO2_db é um dos frameworks integrantes da plataforma de desenvolvimento web PHPO2 que

está sendo desenvolvida. No entanto, ele foi projetado para funcionar totalmente independente,

podendo ser utilizado em qualquer aplicação web que faça uso de PHP. Abaixo são apresentados

objetivos e soluções a que ele se propõe:

1. Desacoplar qualquer necessidade de acesso a dados aos mecanismos que o fazem.

2. Permitir que a fonte de dados seja trocada sem que isto afete a aplicação.

3. Disponibilizar uma interface de acesso aos recursos do framework que seja de domínio da

comunidade.

4. Permitir a integração dos diversos recursos disponibilizados pelo PHP através de uma

interface amigável e de fácil aprendizado.

5. Disponibilizar mecanismos de configuração dos recursos de acesso a dados independentes

da aplicação.

6. Implementar mecanismos de segurança que permitam aplicar as melhores práticas de

mercado.

A figura 2 representa a interface da camada de serviço do framework. Esta interface deverá ser

usada, independente da fonte de dados que o sistema fizer uso.

12

Figura 2 – Interface da camada de serviço do PhpO2_db.


DataProvider: A partir de uma classe de configuração, este componente é o responsável por

retornar um objeto “Connection” selecionado dinamicamente em função da definição do Servidor

de Banco de Dados. Para isso, ele fornece um método estático, o qual permite acesso à

funcionalidade diretamente pela classe DataProvider. Abaixo um exemplo do uso do método:

Figura 3 – Exemplo de método createConnection


13

DbConfig: Classe destinada a fornecer as configurações necessárias aos provedores de acesso a

dados. As configurações deverão ser feitas diretamente nas propriedades da classe, pois por uma

necessidade de segurança, não estão disponíveis métodos para adicionar ou alterar os valores de

suas propriedades.

Dentre as propriedades disponíveis se destacam as três reservadas para os tipos de usuários e suas

respectivas senhas. O objetivo é permitir ao desenvolvedor utilizar usuários com as permissões

adequadas aos requisitos de segurança, dependendo das funcionalidades que serão utilizadas.

Esta classe não estará disponível para ser utilizada pela aplicação, ficando reservada ao Framework.

Na figura 4 são apresentadas as propriedades da classe DbConfig que deverão ser configurada pelo

desenvolvedor.

Figura 4 – Exemplo de configuração de DbConfig


Connection: Interface responsável por estabelecer conexão com o servidor de banco de dados. A

definição da classe concreta de conexão é estabelecida dinamicamente em função das definições

disponibilizadas pela classe DbConfig. A interface Connection disponibiliza, ainda, um método

abstrato responsável por retornar objetos Statement ou StatementCollection. A figura 5 apresenta

exemplos de métodos da classe Connection.

14

Figura 5 – Exemplo de métodos da classe Connection


Statement: Interface responsável executar strings Sql a partir de uma conexão estabelecida. Estão

disponíveis duas classes concretas desta interface, para cada servidor suportado. Uma para executar

comandos únicos e outra para executar uma coleção de string Sql. Ao executar um comando de

consulta, ambas as classes retorna Datasets, seja diretamente, no caso de classes Statement, seja

através da coleção, no caso de classes StatementCollection. A figura 6 apresenta exemplos de

métodos da classe Statement.

Figura 6 – Exemplo de métodos da classe Statement


15

A figura 7 apresenta exemplo do uso do objeto StatementCollection.

Figura 7 – Exemplo de uso da classe StatementCollection


Dataset: Interface responsável por armazenar resultados de consultas Sql a banco de dados. As

classes concretas Dataset implementam métodos de navegação, de iteração e de acesso aos dados

armazenados. A figura 7 mostra exemplo de funcionalidades do Dataset.

Figura 8 – Exemplo de métodos da classe Dataset


16

Desafios de projeto e desenvolvimento do framework PhpO2_db

Dois aspectos principais nortearam o projeto do framework PhpO2_db. O primeiro foi

transferir para o framework a responsabilidade de gerenciamento do acesso às fontes de dados

através de um provedor de dados e a definição de quais componentes e objetos seriam necessários

para fazê-lo. O segundo foi disponibilizar uma camada de serviço – API mais amigável, tal que

promovesse uma abstração das complexidades dos recursos e dos proxys de acesso a gerenciadores

de banco de dados disponibilizados pelo PHP. Este segundo aspecto assumiu uma relevância maior

em virtude das questões apresentadas anteriormente.

Com relação ao primeiro aspecto, o framework disponibiliza um componente DataProvider

responsável pela definição do provedor de acesso que será utilizado pela aplicação. Para tanto, ele

faz uso de uma classe estática de configuração a qual fica responsável pela definição dos

componentes que serão utilizados em função do servidor gerenciador de banco de dados – SGDB

(Figura 2). O componente Dataprovider faz uso do design pattern Factory Method para definir e

retornar quais objetos fará uso, a partir da informação do SGDB disponibilizada pela classe de

configuração. Este método, por ser estático, permite que se tenha acesso a um objeto connection

através de uma chamada pela própria classe. Ele faz uso de um recurso do PHP que permite criar

uma instância de uma classe dinamicamente, como mostra o código da figura 4, abaixo.

Figura 4 – Método fábrica createConnection.


Além de definir dinamicamente a classe que fornecerá a instância de conexão, o método

fabrica também faz a inclusão do arquivo onde a classe foi definida, isto em tempo execução. Para

17

garantir que uma sessão da aplicação não faça uso de mais de uma instância da classe de conexão,

foi utilizado o design pattern Singleton, como mostra a figura 4 (XAVIER, 2011; ZANDSTRA,

2009, GAMMA at. al, 2008).

Como um dos objetivos principais do framework era disponibilizar uma interface amigável

de acesso à camada de servido de acesso aos dados, foram utilizados diversos design patterns,

dentre os quais se destaca o Façade (GAMMA at. al, 2008), o qual permitiu isolar a aplicação

cliente das complexidades e problemas levantados sobre os recursos nativos do PHP, através de

uma interface única e amplamente aceita pela comunidade. A figura 5 mostra as classes de

abstração implementadas pelo padrão Fachada – design patterns Façada.

Figura 5 – Abstrações implementadas pelo design patterns Façada


Estas abstrações fazem uso do design pattern Abstract Factory para definir em tempo de

execução quais classes concretas serão instanciadas, em função das definições fornecidas por uma

classe de configuração.

Como em alguns casos, estas classes fazem uso de classes nativas do PHP, elas também

fazem uso do padrão Singleton para que objetos responsáveis por abrir conexão com banco de

dados forneçam uma única instância deste objeto. Fazem uso também do design pattern Strategy

com a finalidade de estender a estas classes funcionalidades de filtros, tais como filtros contra

injeção de SQL.

O framework introduz, também, instrumentos para a adoção de práticas de segurança aos

dados provenientes de SGDB, disponibilizando ao desenvolvedor o acesso a três níveis de usuários

de banco de dados. Assim o desenvolvedor poderá usar um usuário que tenha somente permissão de

leitura ao banco de dados para algumas das funcionalidades do sistema, bem como usuários com

permissão de leitura e gravação, ou ainda um terceiro com uma permissão mais ampla, quando este

18

for necessário. O gerenciamento deste recurso fica a cargo da classe de configuração, garantindo um

total desacoplamento entre a aplicação e o gerenciamento de permissões (LISBOA, 2013;

ZANDSTRA, 2009; GAMMA at. al, 2008) .

As figuras 6, 7 e 8 apresentam exemplos de aplicação dos padrões adotados.

Figura 6 – Método do uso do padrão Singleton e do padrão de definição de nível de usuário.


Figura 7 – Apresentação da arquitetura a partir dos design patterns adotados


19

Figura 8 – Exemplo do uso do uso do padrão Strategy


Assim como diversos mecanismos maduros de acesso a banco de dados, o framework

PhpO2_db faz uso do design pattern “Command” com o propósito de encapsular as solicitações de

comandos ao banco de dados através da classe abstrata “Statement”.

O framework disponibiliza, ainda, os principais recursos de controles de acesso a dados,

tais como, preparação de consulta SQL, filtros de tratamento de variáveis em função de requisitos

de segurança e controle de transação, etc. Por fim, o framework disponibiliza a classe abstrata

Dataset responsável por armazenar os dados resultantes de uma consulta realizada pelo Statement,

disponibilizando recursos de navegação e iteração pela matriz de resultados.

TRANSAÇÕES

Tirando proveito dos recursos disponíveis no PHP, o framework disponibiliza recursos de

transação a partir dos Servidores de Bancos de Dados que os implementam.

Para usar os recursos de transação do framework será necessário fazer uso dos métodos BEGIN,

COMMIT E ROLLBACK.

20

O método BEGIN abre uma transação no servidor de banco de dados. Este método permite que se

faça uso dos métodos COMMIT E ROLLBACK. O método COMMIT efetiva uma transação, caso

não haja algum problema. Retorna “true” ou “false” no caso de sucesso ou insucesso na transação.

O método ROLLBACK retorna o status anterior do banco de dados antes da transação, desfazendo

possíveis alterações sofridas por este.

TRATAMENTO DE EXCEÇÕES

A partir da versão 5 do PHP estão disponíveis mecanismos maduros de tratamento de

exceções. Estes mecanismos foram adicionados ao framework PHPO2_DB, tal que permita ao

desenvolvedor mais flexibilidade no tratamento de erros e das exceções que são lançadas pelo

framework.

O PHP disponibiliza o bloco TRY para adicionar toda a lógica a ser implementada com os

recursos do framework, e o bloco CATCH para implementar a lógica do tratamento do erro.

Neste caso, o desenvolvedor poderá apresentar a mensagem de erro disparada pela exceção, poderá

redirecionar a outra página usando os recursos do PHP, dentre outras possíveis ações.

Por uma questão de segurança, o framework disponibiliza dois tipos de apresentação das mensagens

de erro, conforme a configuração da classe Dbconfig.

Caso a propriedade status_message da classe DbConfig esteja definida como “DEV”

(desenvolvimento), em caso de exceções, os textos das mensagem de erro serão apresentados. Caso

esteja definida como “PRO” (produção), só serão apresentados o códigos de erro.

Exemplo da aplicação do tratamento de exceções do framework (figura 9).

21

Figura 9 – Exemplo da aplicação do tratamento de exceções do framework


CONCLUSÕES

Neste artigo foram apresentadas algumas das questões que envolveram o projeto e o

desenvolvimento de um framework de acesso a dados em PHP. Foram apresentadas as motivações e

os principais objetivos que levaram ao seu desenvolvimento, bem como, as principais soluções que

foram implementadas, sejam elas viabilizadas por padrões de arquitetura e de projetos maduros,

sejam elas em função da busca de soluções de integração dos diversos recursos que o PHP

disponibiliza.

Por se tratar de uma versão beta, algumas questões foram deixadas para serem tratadas de

forma mais adequada nas próximas etapas do desenvolvimento, particularmente aquelas

22

relacionadas com a gestão de estado de alguns componentes, no entanto, as alterações que

realizadas não afetarão os mecanismos de acesso às suas funcionalidades, ou seja, as mudanças

internas não afetarão sua interface.

Em virtude de estar em fase inicial de desenvolvimento, só estará disponível para download a

biblioteca de acesso ao servidor Mysql. No entanto, já estão em fase de teste os componentes para

outros servidores.

Para aqueles que queiram testar o framework, juntamente com os arquivos do framework,

também está disponível para download o e-book “PHPO2_DB Framework de acesso a dados:

GUIA RÁPIDO” com a descrição da biblioteca de componentes com exemplos detalhados da

aplicação de suas funcionalidades. O download poderá ser feito no endereço HTTP://www

.phpo2.org. Brevemente estará disponível um fórum para troca de experiências e compartilhamento

de conhecimento entre a comunidade.

23

BIBLIOGRAFIA

FLOWLER, M., RICE, D., FOEMMEL, M., HIEATT, E. MEE, R. STAFFORD, R. Padrões de

Arquitetura de Aplicações Corporativas. Bookman, Porto Alegre, 2008.

GAMMA, E., HELM, R., JOHNSON, R., VLISSDES, J. Padrões de Projeto: soluções reutilizáveis

de software orientado a objetos. Bookman, Porto Alegre. 2008.

GUERRA, Eduardo. Design Patterns com Java, Casa do Código, São Paulo, 2008.

HORSTMANN, Cay. Padrões e Projeto Orientados a Objetos. Bookman, Porto Alegre, 2007.

TURBAN, E. MCLEAN, E. & WETHERBE, J. Tecnologia da Informação para Gestão:

transformando os negócios na economia digital, Bookman, Porto Alegre, 2007.

DALL’OGLIO, Pablo. PHP, Programando com Orientação a Objetos. Novatec, São Paulo. 2009.

NIEDERAUER, Juliano. PHP para quem conhece PHP. Novatec, São Paulo. 2008.

SINTES, Anthony. Programação Orientado a Objetos, Makron Books, São Paulo 2010.

SILVA, Maurício Samy, JQuery UI: componentes de interface rica para aplicações web. Novatec,

São Paulo. 2012.

BEBIN, Lee. Ajax com PHP; do iniciante ao profissional. Alta Books. Rio de Janeiro. 2007.

SOARES, Walace. Ajax: Asynchronous Javascript and XML. Érica. São Paulo. 2006.

desafios na construção de -...

Documents