Comment fonctionne l'ORM sous les couvertures? Aussi, quel est le meilleur moyen d'avoir des objets persistants en Java?
https://stackoverflow.com/questions/1231295
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Comment fonctionne l'ORM? Les objets sont-ils sérialisés en BLOB?
En Java, JDO est-il toujours la solution? Quoi d'autre est disponible? On dirait qu’on a beaucoup parlé d’EJB, de la sérialisation directe d’objets et de JDO.
La solution
Pour répondre à votre première question, voici un extrait de Hibernate en action , cela signifie qu'il existe différentes manières de mettre en œuvre ORM:
Pure relationnel
L'ensemble de l'application, y compris le l’interface utilisateur, est conçue autour du modèle relationnel et basé sur SQL opérations relationnelles. Cette approche, malgré ses lacunes pour les grandes systèmes, peut être une excellente solution pour des applications simples où une faible niveau de réutilisation de code est tolérable. Direct SQL peut être ajusté à chaque aspect, mais les inconvénients, tels que manque de portabilité et maintenabilité, sont importants, surtout à long terme. Applications dans cette catégorie souvent faire un usage intensif des procédures stockées, déplacer une partie du travail de la couche métier et dans la base de données.
Mappage d'objet clair
Les entités sont représentées sous forme de classes qui sont mappés manuellement à la tables relationnelles. Codé à la main SQL / JDBC est caché de la logique métier en utilisant des modèles de conception bien connus. Cette approche est extrêmement répandue et réussit pour les applications avec un petit nombre d'entités, ou applications avec générique, modèles de données basés sur les métadonnées. Stockée les procédures pourraient avoir une place dans cette type d'application.
Mappage d'objet moyen
L'application est conçue autour d'un modèle d'objet. SQL est généré à gagner du temps en utilisant une génération de code outil, ou au moment de l'exécution par le code du framework. Les associations entre objets sont soutenu par la persistance mécanisme, et les requêtes peuvent être spécifié en utilisant un orienté objet langage d'expression. Les objets sont mis en cache par la couche de persistance. UNE beaucoup de produits ORM et de chez nous les couches de persistance supportent au moins ce niveau de fonctionnalité. C'est bien adapté aux applications de taille moyenne avec des transactions complexes, en particulier lorsque la portabilité entre différents produits de base de données est important. Ces applications habituellement n’utilisez pas de procédures stockées.
Mappage complet d'objet
Prise en charge complète du mappage d'objets modélisation d'objet sophistiquée: composition, héritage, polymorphisme et & # 8220; persistance par accessibilité. & # 8221; La couche de persistance met en œuvre la persistance transparente; les classes persistantes n'héritent d'aucune classe de base spéciale ou à implémenter une interface spéciale. Stratégies de récupération efficaces (paresseux et désireux chercher) et la mise en cache les stratégies sont mises en œuvre de manière transparente à l'application. Ce niveau de fonctionnalité peut difficilement être atteint par une persistance locale Cette couche est équivalente à des mois ou des mois. années de temps de développement. Un numéro de Java ORM commercial et open source les outils ont atteint ce niveau de qualité. Ce niveau répond aux définition de ORM que nous utilisons dans cette livre. Regardons les problèmes que nous avons attendre à être résolu par un outil qui réalise la mise en correspondance complète des objets.
Autres conseils
ORM = Mappage relationnel d'objet, les attributs des objets sont mappés aux colonnes de la base de données réaliste. Ce mappage est arbitraire, ce qui pourrait être fait pour les blobs. En pratique, ce qui est le plus utile tend aux mappages naturels - Strings to Varchars, int to integers, etc.
JPA est l’endroit idéal pour rechercher un standard pour ORM. JPA remplace l'approche EJB CMP, qui s'est révélée lourde. JPA vous permet d’exprimer le mappage sous forme d’annotations Java et permet également de spécifier les mappages dans des fichiers de configuration. Lorsqu’il prend en charge des bases de données multip [le], ces dernières peuvent être utiles.
JPA dispose d'un langage de requête vous permettant de construire des requêtes sur des attributs d'objet.
JPA est pris en charge par les principaux fournisseurs d'App Server ainsi que par des produits tels que Hibernate.
J'ai trouvé JPA assez agréable à travailler, plus encore que EJB CMP.
Je recommanderais de continuer à utiliser les façades EJB Session Beans pour la gestion des transactions et la sécurité - l'approche basée sur les annotations rend EJB 3 simple à utiliser que EJB 2, avec une surcharge de codage minimale.
JDO est également un ORM standard et fournit une spécification plus complète que JPA (1 + 2). JPQL est plus axé sur les concepts de SGBDR et imite donc SQL. JDOQL suit la syntaxe Java, elle est donc davantage basée sur les objets. Cela dépend si votre application est considérée comme s’éloignant du SGBDR. Si tel est le cas, alors JPA n'est pas la solution. S'il s'agit uniquement d'un SGBDR, alors JPA est définitivement une considération.
La question de savoir si les objets sont sérialisés en BLOB dépend de votre configuration. Vous pouvez le faire pour des types d'objet complexes si vous le souhaitez, mais ils ne seront alors plus interrogeables. Si au lieu de cela, vous les conservez sous une forme native, vous pouvez également les interroger, ce qui conduit à des applications plus efficaces.
- Andy (DataNucleus - Persistance JDO et JPA)
