+2

Mapeamento Objeto-Relacional da Teoria à Prática

criado por Diego Botelho Martins em 29/07/2007 3:37pm
Salve comunidade!

Neste artigo irei falar resumidamente sobre mapeamento objeto-relacional que consiste em uma abordagem que permite a construção de sistemas utilizando o paradigma da orientação a objetos com a persistência destes objetos em bancos de dados relacionais como o Mysql.

Utilizando-se de técnicas e estratégias específicas, é possível mapear classes com seus atributos e associações para o modelo relacional.

Os bancos de dados orientados a objeto são mais adequados para a persistência de objetos manipulados por aplicações orientadas a objeto, devido à utilização do mesmo paradigma. Porém a indisponibilidade atual destes bancos de dados, seja devido ao custo, diversidade ou amadurecimento do mercado, faz com que seja necessária a busca de alternativas para a realização da persistência.

Desenvolvendo projetos desta maneira você estará contribuindo para a reutilização do seu código em diferentes áreas do seu sistema e até mesmo de projetos futuros, sem falar da legibilidade e do aspecto profissional agregados ao seu código.

Mais como seria esse mapeamento na prática?

Suponha que tenhamos as seguintes tabelas do DER abaixo no nosso banco de dados:

+------------------------+   
|cli_clientes            |                   +--------------------------+
+------------------------+                   |cat_categorias            |
|cli_id int(10)          |                   +--------------------------+
|cli_idCategoria int(10) | n ------------- 1 |cat_id int(10)            |
|cli_nome varchar(50)    |                   |cat_nome varchar(50)      |
|cli_cpf varchar(20)     |                   +--------------------------+
|cli_email varchar(30)   |
+------------------------+

A partir delas iremos construir nossas classes, lembrando que a ordem não importa, conheço algumas pessoas que costumam fazer a modelagem do banco de dados primeiro, depois as tabelas e outras que modelam primeiro seus objetos para somente então, partir para a construção do DER.

Abaixo está o diagrama de classes que representa as tabelas do DER:

Obs.: Sinais de visibilidade de atributos e métodos utilizados seguindo os padrões da UML
Onde o sinal de "+" => private; "-" => public; "#" => protected

+----------------------------------+   
|             Cliente              |                   +------------------------------+
+----------------------------------+                   |          Categoria           |
|+ int cli_id                      |                   +------------------------------+
|+ int cli_idCategoria             | ----------------> |+ cat_id                      |
|+ Categoria objCategoria          |                   |+ cat_nome                    |
|+ string cli_nome                 |                   +------------------------------+
|+ string cli_cpf                  |                   |- setId($intId)               |
|+ string cli_email                |                   |- getId()                     |
+----------------------------------+                   |- setNome($strNome)           |
|- setId($intId)                   |                   |- getNome()                   |     
|- getId()                         |                   |- __construct()               |
|- setIdCategoria($intIdCategoria) |                   |- __destruct()                |
|- getIdCategoria()                |                   |- cadastrar()                 |
|- setCategoria($objCategoria)     |                   |- alterar()                   |
|- getCategoria()                  |                   |- excluir()                   |
|- setNome($strNome)               |                   |- carregar()                  |
|- getNome()                       |                   |- listar()                    |
|- setCpf($strCpf)                 |                   +------------------------------+
|- getCpf()                        |
|- setEmail($strEmail)             |
|- getEmail()                      |
|- __construct()                   |
|- __destruct()                    |
|- cadastrar()                     |
|- alterar()                       |
|- excluir()                       |
|- carregar()                      |
+----------------------------------+

No diagrama de classes, cada tabela do banco de dados foi mapeada para uma classe, onde o nome da classe é o mesmo nome da tabela só que no singular e sem o prefixo.

Os atributos possuem visibilidade private, ou seja, somente os métodos internos a classe é que poderão acessá-los diretamente, para objetos externos acessarem estes atributos, deve-se utilizar as propriedades modificadoras, os famosos get e set, se o atributo for somente de leitura você pode omitir a propriedade set.

O método __construct pode ser utilizado para setar os valores default de cada atributo.


Relacionamentos:

No DER temos o relacionamento 1 para n indicando que uma categoria pode conter nenhum ou vários clientes, porém um cliente só está ligado a uma categoria.

Para construir o relacionamento inserimos a chave estrangeira cli_idCategoria na tabela de clientes ligando-a com a chave primária cat_id da tabela de categorias.

No diagrama de classes também temos os atributos cli_idCategoria e cat_id, só que como o objeto Cliente é responsável por conhecer a sua categoria, criamos o atributo objCategoria na classe Cliente, desta forma, assim que utilizarmos o método $objCliente->carregar(), este terá que chamar o método $this->objCategoria->carregar().

Estes métodos devem recuperar os dados de um determinado registro no banco e setá-los em cada atributo do objeto.

Para que possamos identificar qual registro deve ser recuperado, setamos o id do objeto:

<?php
$objCliente = new Cliente;
$objCliente->setId('3');
$objCliente->carregar();

echo $objCliente->getNome();
echo $objCliente->getCpf();
echo $objCliente->getCategoria()->getNome();
?>

A implementação dos métodos CRUD (Create, Read, Update e Delete), ou seja, cadastrar, carregar, alterar e excluir, vai depender de quantas camadas sua aplicação estará dividida.

O ideal é que nas classes Cliente e Categoria você só realize operações envolvidas com a camada de negócios, fazendo com que estes métodos chamem outros métodos de uma camada de nível mais baixo, como por exemplo DaoCliente::carregar() e DaoCategoria::carregar(). (Dao vem de Data Access Object)

Estas classes sim é que poderiam ter métodos com cláusulas SQL como SELECT, INSERT, UPDATE E DELETE.

Da mesma forma, você pode criar classes de nível mais alto para gerenciar a camada de apresentação, nestas classes você irá tratar códigos HTML, Javascript, CSS e etc.

Codificando desta forma seus objetos ficarão muito mais reutilizáveis!!

Então chega de conversa e mãos a obra! Na próxima página postei o código fonte das classes...

Comentários:

Mostrando 1 - 2 de 2 comentários
Muito bom Diego! Legal ver que a galera do PHP está antenada com relação a orientação a objetos.

Lembrando que o design pattern que você usou é o Active Record (http://www.martinfowler.com/eaaCatalog/activeRecord.html) e o Data Access Object (http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html).

No caso do Active Record, um ponto contra é que as rotinas de persistência estão fortemente acopladas ao objeto, o que pode não ser o cenário ideal para todas as situações. Algumas vezes é melhor separar as rotinas de cadastro, exclusão, seleção e atualização em um objeto separado. ;)
31/07/2007 3:49am (~16 anos atrás)

Diego parabéns pelo artigo, excelente mesmo, são poucos que tem essa mentalidade de OO, muitos não sabem o que é e outros não sabem como implementar, esse seu artigo ficou muito bom, uma unica duvida que eu fiquei é de como q ficaria a implementação desse DAO, já ouvi falar disso mas não pesquisei nada ainda se puder colocar mais um artigo explanando sobre esse assunto acho q seria bem interressante, ou se tiver algum material e puder me enviar fico muito grato.

Parabéns.
30/07/2007 9:11am (~16 anos atrás)

Novo Comentário:

(Você pode usar tags como <b>, <i> ou <code>. URLs serão convertidas para links automaticamente.)