Como funciona o ORM debaixo das cobertas? Também o que é a melhor maneira de ter objetos persistentes em Java?

Question

Como funciona o ORM? objetos são serializados em BLOBs?

Em Java, é JDO ainda o caminho a percorrer para isso? O que mais está disponível? Parece que havia um monte de falar de EJB, serialização objeto direto, e JDO.

Answer 1

Para responder à sua primeira pergunta, aqui é um extracto de Hibernate em Ação , que diz que existem várias maneiras de implementar ORM:

Pure relacional

Toda a aplicação, incluindo o interface do usuário, é projetado em torno do modelo relacional e baseado em SQL operações relacionais. Esta abordagem, apesar de suas deficiências para grandes sistemas, pode ser uma excelente solução para aplicações simples, onde um baixo nível de reutilização de código é tolerável. Direta SQL podem ser ajustadas em cada de aspecto, mas as desvantagens, tais como falta de portabilidade e manutenção, são significativos, especialmente no longo prazo. As aplicações nesta categoria, muitas vezes fazem uso pesado de procedimentos armazenados, deslocando alguns dos trabalhos fora do camada de negócios e no banco de dados.

mapeamento objeto Luz

As entidades são representadas como classes que são mapeados para o manualmente tabelas relacionais. Mão-codificado SQL / JDBC está escondido da lógica de negócios usando padrões de projeto bem conhecidos. Esta abordagem é extremamente difundido e é bem sucedido para aplicações com um pequeno número de entidades, ou aplicações com genérico, modelos de dados metadados-dirigido. armazenada procedimentos pode ter um lugar neste tipo de aplicação.

mapeamento objeto Médio

O aplicativo é projetado em torno de um modelo de objeto. SQL é gerado pelo tempo de compilação usando uma geração de código ferramenta, ou em tempo de execução pelo código do framework. Associações entre os objetos são suportado pela persistência mecanismo, e pode ser consultas especificada utilizando uma orientada objeto- linguagem de expressão. objetos são cache pela camada de persistência. UMA muitos produtos ORM e homegrown camadas de persistência suportar pelo menos este nível de funcionalidade. Está bem adequado para aplicações de médio porte com algumas transações complexas, particularmente quando a portabilidade entre produtos de banco de dados diferentes é importante. Estas aplicações geralmente não usar procedimentos armazenados.

mapeamento objeto completa

objeto completa suportes de mapeamento sofisticada modelagem de objetos: composição, herança, polimorfismo, e “persistência por acessibilidade." A camada de persistência implementa persistência transparente; classes persistentes não herdam qualquer classe base especial ou tem que implementar uma interface especial. estratégias de fetching eficientes (preguiçoso e busca antecipada) e cache estratégias são implementadas de forma transparente para a aplicação. este nível de funcionalidade pode ser mal conseguida por um caseiro persistência camada é equivalente a meses ou anos de tempo de desenvolvimento. Um número da fonte comercial e de código aberto Java ORM ferramentas de ter alcançado este nível de qualidade. Este nível encontra o definição de ORM estamos usando neste livro. Vamos olhar os problemas que Esperar para ser resolvido por uma ferramenta que alcança mapeamento objeto completo.

Answer 2

= ORM objecto relacional Mapeamento, atributos dos objectos são mapeados para colunas no banco de dados realational. Esse mapeamento é arbitrária, de modo que poderia ser feito para blobs, na prática, o que é mais útil tende a mapeamentos naturais -. Cordas para VARCHARs, int para inteiros etc

APP é o lugar para procurar um padrão para ORM. JPA substitui a abordagem EJB CMP, que foi encontrado para ser pesado. JPA lhe permite expressar o mapeamento como anotações Java e também permite que os mapeamentos de ser especificados em arquivos configutration, ao apoiar multip [le bases de dados o último pode ser útil.

JPA tem uma linguagem de consulta para que você possa construir consultas contra atributos de objeto.

JPA é apoiado pelos principais fornecedores App Server e também por produtos como o Hibernate.

Eu encontrei JPA muito bom trabalhar com, mais do que EJB CMP.

Eu recomendaria ainda usando Sessão EJB Feijão fachadas para mamangement transação e segurança -. A abordagem baseada em anotações faz EJB 3 maneira fácil de usar do EJB 2, mínimo de codificação sobrecarga

Answer 3

JDO é realmente ORM padrão também, e fornece uma especificação de uma forma mais completa do que APP (1 + 2). JPQL é mais focado em conceitos de RDBMS e, portanto, imita SQL. JDOQL segue a sintaxe Java para se baseia mais objeto. Depende se o seu aplicativo é já considerou a ir longe de RDBMS. Se sim, então JPA não é o caminho a percorrer. Se for apenas para RDBMS, em seguida, JPA é definitivamente uma consideração.

objetos Quer são serializado em BLOBs depende da configuração. Você pode fazer isso para tipos de objetos complexos, se desejar, mas então eles não serão queryable. Se você em vez persistem-los em uma forma nativa, então você também pode consultá-los, levando a aplicações mais eficientes.

- Andy (DataNucleus - JDO e JPA persistência)