Neste artigo abordaremos um assunto de suma importância para projetos desenvolvidos orientados a objetos, a persistência de dados. Independente da linguagem que você adotar para desenvolver seu projeto você sempre irá esbarrar em um problema: seus objetos estão na memória e você precisa persisti-los em um repositório de dados, geralmente um SGBD, então vem a questão: Como transformar meus objetos em comandos SQL? Veremos aqui uma forma simples e rápida para resolver isso.
Para que serve
O mapeamento objeto / relacional, tema do nosso artigo, serve para resolver a impedância que temos entre os modelos de negócio orientados a objetos e os bancos relacionais. Isso porque a linguagem padrão dos SGBD é SQL, sendo assim, temos que mapear nossos objetos extraindo deles suas informações para então montar a instrução e enviar para o banco de dados. Os frameworks de persistência, como o Lumine (estudado neste artigo), nos auxiliam neste processo.
Em que situação o tema é útil
A utilização de mecanismos de mapeamento objeto / relacional aumenta a produtividade e reduzem o tempo de desenvolvimento de um projeto, uma vez que o desenvolvedor foca sua atenção apenas nas regras de negócio, deixando o trabalho pesado por conta do framework. Será necessário um tempo para conhecer e se familiarizar com o framework, porém, o tempo é recuperado ao longo do desenvolvimento do projeto.
Resumo do DevMan
Quando definimos uma solução, temos que pensar qual arquitetura utilizar, quais padrões, plataforma e no caso de persistência, qual framework de mapeamento. Para Java temos o Hibernate, em .NET temos o ADO.NET Entity Framework, NHibernate e outros. E para o PHP temos o Lumine. Neste artigo vamos entender o que são e para que servem os frameworks de persistência. Iremos conhecer o Lumine, um framework de persistência objeto relacional para PHP, 100% Free e muito intuitivo. Para demonstrar isso vamos desenvolver um pequeno exemplo totalmente orientado a objetos.
Hoje em dia as principais linguagens de programação no mercado são orientadas a objetos ou suportam orientação a objetos como alguns gostam de falar, e isso é muito bom. A orientação a objetos é uma filosofia de desenvolvimento que nos permite uma melhor organização e reaproveitamento do código. Ela também nos permite, entre outras coisas, mapear nossas entidades do mundo real para o mundo computacional. Em paralelo a este crescimento da orientação a objetos vemos também um crescimento e consolidação dos bancos de dados relacionais que têm como linguagem padrão a SQL.
Num projeto orientado a objetos temos nossas regras de negócio mapeadas, ou melhor, descritas em nossas classes. Para que possamos de fato e de verdade lançar mão destas regras, temos que instanciar objetos a partir destas classes. Uma vez tendo feito isso, nosso objeto reside na memória pronto para receber os dados enviados pelo usuário e aplicar suas regras.
Esse é um dos motivos que nos levam a trabalhar como banco de dados, armazenar nossas informações para posterior consulta. Mas se tratando de objetos não podemos esquecer que os mesmos estão instanciados na memória e não podemos simplesmente pegá-los e jogá-los em um banco de dados, até porque os SGBD relacionais utilizam SQL. É aí que surge o que muitos chamam de impedância objeto relacional, uma vez que, se não trabalharmos com banco de dados orientados objetos, não temos outro jeito de salvá-los em um SGBD relacional sem que seja mapeando o objeto para SQL, o famoso mapeamento objeto / relacional.
Mapeamento objeto / relacional implica em ler um objeto e dependendo do que se deseja fazer com ele, gerar o comando SQL correspondente, seja um Insert, Update ou Delete. Um padrão muito usado para isso é o DAO, que prega que para cada classe de negócio em nosso modelo temos que ter uma classe de persistência que irá se encarregar da comunicação com o banco de dados e gerar os comandos para a persistência. Você pode estar pensando: “Mas isso pode dar muito trabalho”, e é verdade, ainda mais se em seu sistema você possuir um número muito grande de classes.
...
