Atenção: esse artigo tem um vídeo complementar. Clique e assista!
A idéia do artigo é apresentar o uso da extensão PDO (PHP Data Objects), mostrando a criação de uma aplicação na prática. O artigo está dividido em duas partes. Nesta primeira parte apresentaremos o projeto e construção do banco de dados do estudo de caso que será construído utilizando PDO.
Para que serve:
PHP Data Objects (PDO) trata-se de uma interface de acesso a banco de dados (ao contrário de uma camada de abstração total, esta extensão não gera SQL automaticamente). É uma extensão relativamente nova e tem como objetivo padronizar o acesso a banco de dados usando as mesmas funções independentemente do banco que será realizado a conexão e manipulação de dados. A mesma está disponível desde a versão 5.1 do PHP, ou até mesmo em sua versão 5.0, que pode ser utilizada com a instalação da extensão PECL.
Em que situação o tema é útil:
Todos nós desenvolvedores/analista já passamos por situações com clientes que precisaram migrar o seu banco de dados de dados para outro. Isso é muito comum, não só em PHP, mais como qualquer outra tecnologia. Neste artigo será apresentada a extensão PDO, uma biblioteca nativa do PHP, utilizando o padrão DAO, tornando sua aplicação otimizada e flexível.
Uma das grandes desvantagens do acesso a dados do PHP sempre foi a não unificação em apenas uma tecnologia. É comum utilizarmos funções específicas para cada banco de dados que manipulamos em nossas aplicações. No banco de dados MySQL, por exemplo, temos disponíveis as funções mysql_connect, mysql_select_db, mysql_query, mysql_fetch_array, dentre outras. No SGBD PostgreSQL temos disponíveis as funções pg_connect, pg_select_db, pg_query, pg_fetch_array.
Agora imagine quando desenvolvemos uma grande aplicação para uma empresa e por algum motivo, seja de verbas, desempenho ou qualquer outra situação que aconteça, tenhamos que migrar para outros bancos de dados. Com certeza seria um grande problema, e praticamente todo sistema precisaria ser revisado e modificado. Apesar das funções conterem nomenclaturas similares, algumas delas necessitam de informações diferentes em seus parâmetros.
O objetivo deste artigo é apresentar a extensão PDO (PHP Data Object) do PHP, e com isso alguns desses problemas com certeza serão contornados. Para termos um ganho maior de aprendizado, o artigo segue uma direção para a construção de uma aplicação financeira, de contas a pagar e receber, mostrando o padrão DAO e a produtividade e desempenho que ganhamos com a PDO. Além disso, a flexibilidade que temos para em poucos segundos migrar a aplicação para outro banco de dados, neste caso, do MySQL para PostgreSQL. Outro fator importante a salientar é que pelo fato de alguns bancos de dados terem suas peculiaridades, PDO não gera SQL automaticamente, como citado acima. Por isso, dependendo de sua consulta SQL é preciso alterá-la para que fique adequado ao banco de dados correspondente, já que cada banco tem suas particularidades.
O artigo está dividido em duas partes. A primeira parte irá descrever o projeto e construção do banco de dados do nosso estudo de caso. Na segunda parte, será apresentado o desenvolvimento do nosso estudo de caso utilizando PDO para apoiar na comunicação entre os diferentes tipos de banco de dados.
Estudo de Caso – Aplicação de Contas a Pagar e Receber
Antes de iniciarmos a construção propriamente dita do software, é importante entender a idéia do sistema que será desenvolvido ao longo deste artigo. Como citado no começo, a idéia é criar uma aplicação financeira de contas a pagar e receber. Esta aplicação será bastante simples, mas irá lhe mostrar uma visão bastante rica e ampla da portabilidade que é possível através da extensão PDO.
Uma aplicação de contas a pagar e receber é bastante simples. Como o próprio nome sugere, será um cadastro de contas, onde uma conta a pagar será lançada a um fornecedor e uma conta a receber será recebida de clientes. O sistema será composto também por cadastro de clientes e fornecedores, conforme você pode perceber pelo contexto do mesmo, citado acima. Outro ponto importante do artigo é desenvolver a aplicação isolando o acesso aos dados em uma classe DAO (ver Nota DevMan 1).
Nota DevMan 1. DAO (Data Access Object) e MVC (Model-View-Controller)
Atualmente o modelo preferido para persistir dados em aplicações é debanco de dadosrelacional.
DAO (Data Access Object) é um padrão para persistência de dados que permite separar regras de negócio das regras de acesso a banco de dados. Numa aplicação que utilize a arquiteturaMVC, todas as funcionalidades de bancos de dados, tais como obter as conexões, mapear objetos para tipos de dadosSQLou executar comandos SQL, devem ser feitas por classes de DAO.
Model-view-controller (MVC) é um padrão de arquitetura de software. Com o aumento da complexidade das aplicações desenvolvidas, torna-se fundamental a separação entre os dados (Model) e o layout (View). Desta forma, alterações feitas no layout não afetam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout.
O padrão MVC resolve este problema através da separação das tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de interação com o utilizador, introduzindo um componente entre os dois: o Controller. MVC é usado em padrões de projeto de software, mas MVC abrange mais da arquitetura de uma aplicação do que é típico para um padrão de projeto.
Projetando o Banco de dados
Como mencionado no inicio deste artigo, o grande diferencial da biblioteca PDO é sem dúvida sua simplicidade para acesso a dados. Realizando uma analogia mais complexa de um sistema de contas a pagar e receber, é bastante simples o seu entendimento. Conforme você pode observar na Figura 1, temos basicamente quatro tabelas, onde os próprios nomes sugerem suas características dentro do contexto da aplicação.
Na tabela de clientes, por exemplo, você tem uma chave primária denominada id_cliente, além de atributos para nome, fone, email e endereço do cliente. Por fim, também existe o atributo cpf_cliente, o que indica que neste contexto um cliente é uma pessoa física. Esta tabela possui um relacionamento com a tabela de contas a receber.
Este é o principio básico da aplicação, onde um cliente se relaciona com uma conta a receber. Neste conceito, você tem uma relação de “1:N” (um para muitos), onde um cliente pode ter muitas contas a receber, mas uma conta a receber só pode estar associada a um cliente. Em uma conta a receber você pode observar a questão do documento, podendo ser um número de cheque, boleto bancário ou qualquer outra guia. Nos campos valor, status e vencimento, são representados respectivamente o valor da conta a ser recebida, o status do pagamento e a data de vencimento.
Veja que as tabelas clientes e contasreceber são bastante simples e intuitivas. A mesma coisa acontece com as tabelas de fornecedores e contaspagar. Se uma conta a receber representa algo a ser pago por um cliente, uma conta a pagar equivale ao pagamento a ser realizado por um fornecedor. Na tabela fornecedores, você pode conferir os campos id_fornecedor como a chave primária da tabela. Os campos nome_fornecedor, fone_fornecedor, email_fornecedor, cnpj_fornecedor e endereco_fornecedor, para fins de informação, caracterizam um fornecedor em nosso estudo de caso como sendo uma pessoa jurídica.
Para fins de comparação entre clientes e fornecedores, sua única diferença é o atributo CPF e CNPJ. Como citado anteriormente, em nosso sistema um cliente é uma pessoa física, e fornecedor é uma pessoa jurídica.
Nos próximos tópicos será comentado um pouco mais sobre a proposta do sistema. Esta proposta parte do princípio de que uma empresa financeira contrata uma software-house para o desenvolvimento de uma aplicação.
