JDO vs JPA para Java no Google App Engine

StackOverflow https://stackoverflow.com/questions/1418219

Pergunta

Eu quero desenvolver meu projeto no Google App Engine com Struts2. Para o banco de dados Eu tenho duas opções JPA e JDO. vocês vai agradar a sugerir-me sobre ele? Ambos são novos para mim e eu preciso aprender. Então eu vou ser focado em um após suas respostas.

Graças.

Foi útil?

Solução

JPA é padrão da Sun para persistência, JDO é IMHO morrendo (na verdade, ele está morto, mas ainda em movimento). Em outras palavras, JPA parece ser um investimento melhor no longo prazo. Então eu acho que eu escolheria JPA se ambos eram novos para mim.

Outras dicas

O grupo GAE / J google tem vários posts sobre isso mesmo. Eu faria uma pesquisa sobre lá e olhar para opiniões das pessoas. Você receberá uma mensagem muito diferente para as opiniões expressas acima. Incidir também sobre o fato de que BigTable não é um RDBMS. Use a ferramenta certa para o trabalho

Só vi essa comparação entre JPA e JDO por DataNucleus si: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Um abrir de olhos.

Eu sou um usuário feliz da JDO. Mantenha-os caras bom trabalho.

As pessoas que reivindicam JDO é morto não é sem mérito. Aqui está o que eu li no livro Pro EJB 3 Java Persistence API: "Pouco tempo depois a Sun anunciou que JDO seria reduzido para modo de manutenção especificação e que o Java Persistence API iria tirar tanto JDO e os outros fornecedores de persistência e se tornar o único suportado padrão daqui para frente. ". O autor Mike Keith é o líder co-especificação sobre EJB3. É claro que ele é um grande defensor da JPA, mas eu duvido que ele é tendencioso suficiente para mentira.

É verdade que quando o livro foi publicado, a maioria dos principais fornecedores foram unidos em torno JPA em vez de JDO, embora JDO tem características técnicas mais avançadas do que JPA. Não é surpreendente, porque grandes jogadores no mundo da EE como a IBM / Oracle também são grandes fornecedores de RDBMS. Mais clientes estão usando RDMBS do que não-RDMBS em seus projetos. JDO estava morrendo até GAE deu um grande impulso. Faz sentido, porque armazenamento de dados GAE não é banco de dados relacional. Alguns JPA apresenta não funciona com Bigtable, tais como consultas de agregação, Junte-se a consultas, de propriedade muitos-para-muitos relacionamentos. Aliás, GAE suportes JDO 2,3 enquanto suportam apenas APP 1.0. Vou recomendar JDO se GAE é a sua plataforma cloud alvo.

Para o registro, ele é o Google App Engine (GAE), para que jogar com o Google não governa com as regras do Oracle / Sun.

De acordo com ele, JPA não é adequado para GAE, é instável e não funcionar como esperado. Nem o Google está disposto a apoiá-lo, mas o mínimo.

E por outro, JDO é bastante estável em GAE e é (em certa medida) bem documentado pelo Google.

No entanto, o Google não recomenda nenhum deles.

http://code.google.com/appengine/docs/ java / datastore / overview.html

Baixo nível API dará o melhor desempenho e GAE é tudo sobre o desempenho.

http://gaejava.appspot.com/

Por exemplo, adicionar 10 entidade

Python: 68ms

JDO: 378ms

Java Native: 30ms

Na corrida entre JDO vs JPA só posso concordar com as DataNucleus cartazes.

Em primeiro lugar, e também o mais importante, os cartazes de DataNucleus sabem o que estão fazendo. Eles são, afinal, o desenvolvimento de uma biblioteca persistente e estão familiarizados com outros que o relacional, por exemplo, modelos de dados Mesa grande. Estou certo de que ID de um desenvolvedor para hibernar estivesse aqui, ele teria que dizer:. "Todas as nossas suposições quando construindo nossas bibliotecas centrais estão fortemente acoplados ao modelo relacional, o Hibernate não é otimizado para GAE"

Em segundo lugar, JPA é, inquestionavelmente, na utilização mais generalizada, sendo uma parte da pilha oficial Java EE ajuda um pouco, mas isso não significa necessariamente que é melhor. Na verdade, JDO, se você ler sobre isso, corresponde a um nível mais alto de abstração do que JPA. APP está intimamente ligado ao modelo de dados RDBMS.

Do ponto de vista de programação, usando o APIs JDO é uma opção muito melhor, porque você está conceitualmente comprometer muito menos. Você pode mudar, teoricamente a qualquer modelo de dados do seu desejo, desde que o provedor que você usar suportes banco de dados subjacente. (Na prática, você raramente atingir um elevado nível de transparancy tal, porque você vai encontrar-se definir as chaves primárias no objeto do GAE e você vai estar amarrando-se a um provedor de banco de dados específico, por exemplo, Google). será ainda mais fácil migrar embora.

Em terceiro lugar, você pode usar o Hibernate, Eclipse Link e até mesmo primavera com GAE. Google parece ter feito um grande esforço para permitir que você use os quadros que você são utilizados para a construção de suas aplicações on. Mas o que as pessoas percebem quando construir seus aplicativos GAE como se estivessem em execução no RDBMS é que eles são lentos. Mola no GAE é lento. Você pode google vídeos do Google IO sobre este tema para ver que é verdade.

Além disso, aderindo aos padrões é uma boa coisa sensata a fazer, em aplaudir princípio eu. Por outro lado, JPA sendo parte da pilha Java EE torna as pessoas, às vezes, perdem a noção de opções. Perceba, se quiserem, que o Java Server Faces também é parte da pilha de Java EE. E é uma solução arrumada incrivelmente para o desenvolvimento GUI web. Mas no final, por que as pessoas, as pessoas mais inteligentes, se assim posso dizer, se desviam deste padrão e usar o GWT vez?

Em tudo isso, eu tenho que sate que há uma coisa muito importante ir para JPA. Isso é Guice e seu apoio conveniente para JPA. Parece que o Google não era tão inteligente como é habitual neste ponto e está contente, pois agora em não apoiar JDO. Eu ainda acho que eles podem pagar, e, eventualmente, Guice vai engolir JDO, bem como, ... ou talvez não.

Go JDO. Mesmo se você não tem experiência em TI, não é difícil de pegar, e você terá uma nova habilidade com o seu cinto!

O que eu acho que é terrível sobre o uso JDO no momento de escrever este é que o único fornecedor de implementação é Datanucleus e as desvantagens de que é a falta de concorrência que leva a inúmeras questões como:

  1. A documentação não muito detalhada sobre alguns aspectos como extensions
  2. Você normalmente obter respostas sarcásticas dos autores como (você tem verificado os logs? Pode ser que haja uma razão para tê-los) e respostas irritantes como aquele
  3. Você não obter uma resposta para a sua pergunta em uma quantidade útil de tempo, por vezes, se você receber uma resposta em menos de 7 dias, você deve considerar a sua auto sorte, mesmo aqui na StackOverflow

Eu estou sempre esperando por alguém para começar a implementar a especificação JDO si, pode ser, em seguida, eles vão oferecer algo mais e espero que mais livre atenção para a comunidade e nem sempre se preocupar com sendo pago suporte, sem dizer que os autores Datanucleus só se preocupam com suporte comercial, mas eu só estou dizendo.

Eu considero pessoalmente autores Datanucleus tem nenhuma obrigação de Datanucleus si nem da comunidade. Eles podem cair todo o projeto a qualquer momento e ninguém pode julgá-los por isso, é seu esforço e sua própria propriedade. Mas você deve saber o que você está se metendo. Você vê, quando um de nós desenvolvedores olhar para um quadro de usar, você não pode punir ou comandar o autor do quadro, mas, por outro lado, é necessário o trabalho feito! Se você tivesse tempo para escrever esse quadro, por que você iria procurar um em primeiro lugar?!

Por outro lado, a própria JDO tem algumas complicações como ciclo de objetos vida e outras coisas que não é muito intuitivo e comum (eu acho).

Edit: Agora eu também sei Enforces JPA o mecanismo de ciclo de vida do objeto, de modo que ele se parece com sua inevitável para lidar com estados de ciclo entidades persistiram vida se você quiser usar um API ORM padrão (ou seja JPA ou JDO)

O que eu gosto mais sobre JDO é a capacidade de trabalhar com qualquer sistema de gerenciamento de banco de dados sem esforço considerável.

GAE / J está programado para adicionar MYSQL antes do final do ano.

APP é o caminho a percorrer, uma vez que parece ser empurrado como uma API padronizada e tem recentemente impulso em EJB3.0 .. JDO parece ter perdido o vapor.

Nem!

Use Objectify, porque é mais barato (usar menos recursos) e é mais rápido. FYI: http://paulonjava.blogspot.mx/2010/12/tuning -Google-appengine.html

Objectify é um acesso a dados API Java projetado especificamente para o armazenamento de dados do Google App Engine. Ocupa um "meio termo"; mais facil de usar e mais transparente do que JDO ou JPA, mas significativamente mais conveniente do que a API de baixo nível. Objectify é projetado para fazer novatos imediatamente produtiva mas também expor o poder do GAE armazenamento de dados.

Objectify permite persistir, recuperar, excluir e consulta seus próprios objetos digitados. 

@Entity
class Car {
    @Id String vin; // Can be Long, long, or String
    String color;
}

ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);
Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top