Bluetooth

A grande sacada da utilização dessa abordagem é o nível de abstração das operações com os dados, pois dependendo da estratégia utilizada, temos a nítida sensação de que estamos trabalhando com os dados sempre em memória, devido as chamadas a base estarem totalmente isoladas e “automáticas” do ponto de vista da camada de domínio da aplicação. Em Java, temos o JPA (Java Persistence API), que descreve uma especificação dizendo como os fabricantes devem desenvolver seus frameworks, algo que é muito interessante, pois isso possibilita a troca de uma implementação por outra quase sem alterações (a menos que esteja usando algum recurso fora da especificação). Se mudamos nossa base Oracle, podemos trocar nosso ORM de Hibernate para TopLink, por exemplo, em troca de um possível ganho de performance. Em outras linguagens temos o ADO.NET para .NET, ActiveRecord para Ruby, no próprio Java temos IBates, etc.

Desvantagens
Como nem tudo são flores, temos alguns contras que existem quando se decide usar algum tipo de ORM. A primeira grande desvantagem é a performance. Num ambiente relacional, temos todos aqueles algorítimos que os bancos de dados usam para a recuperação dos dados, são de longe muito mais performáticos do que qualquer outro tipo de tratamento dos dados na aplicação. Outra desvantagem é a complexidade e o nível de entropia que é necessário para construir-se um bom design. Não é tão simples desenhar a arquitetura de um sistema utilizando uma estratégia desse tipo, o que pode ocasionar designs fracos e ruins, como disse anteriormente. As vezes, utilizado de maneira incorreta, o mapeamento pode acabar separando das entidades os dados e as regras de negócio. Do ponto de vista OO isso é um pouco estranho, pois um carro, por exemplo, contém tudo dentro de um objeto carro, certo? Ou na vida real existe um objeto Carro e outro DadosCarro? Para resolver esse problema podemos recorrer a alguns padrões (Factory, DAO, Repository), mas como percebe-se, a complexidade foi