Je dois commencer un projet de taille moyenne en Java, mais je ne suis pas un grand fan des ORM en général donc la question est: Dois-je concevoir le projet avec un ORM en tête (pour une utilisation ultérieure) ou non?ORM: Oui ou non?
Le SGBDR est Oracle 10g et les requêtes seront très couplées à la syntaxe/fonctions Oracle (c'est-à-dire texte, exploration, CONNECT BY, etc ...).
Merci beaucoup.
Vous voudrez peut-être examiner cette question antérieure qui traite de l'avantage de ORM: What are the advantages of using an ORM?
La partie la plus pertinente (extrait de la réponse acceptée):
Si vous avez complexe, main SQL ajusté, il n'y a pas beaucoup de point dans l'utilisation d'un ORM.
Si vous passez constamment devant l'ORM et écrivez votre propre SQL, l'ORM risque de finir par vous gêner.
Cela dépend ...
Et vous ne devez pas utiliser un ORM pour chaque accès DB ...
Depuis je ne suis pas autorisé à commenter votre commentaire post Ill comme cela (manque de points).
Serait bon pour la discussion POURQUOI vous n'aimez pas ORM.
Imo, je voudrais y aller. Et si, pour une raison quelconque, vous trouvez une requête qui est lente par l'ORM, alors je le ferais moi-même. Tout simplement parce que vous utilisez un ORM la plupart de vos tâches ne signifie pas que vous devez l'utiliser pour tous. Mais oui, ce serait préférable.
Un autre avantage avec un ORM est qu'il aura l'air très bien sur votre CV. La plupart des emplois annoncés aujourd'hui (au moins Java devs) nécessitent une certaine connaissance des ORM. Donc, si vous avez la chance de travailler sur un projet, je choisirais Spring et Hibernate car cela va vraiment booster votre CV. Je pensais que le lien à l'autre question couvrait plutôt bien les avantages techniques, donc je ne dirai rien à leur sujet.
C'est un bon point. –
Donc, mettre bas "développeur Oracle Hard Core" et être en mesure d'expliquer pourquoi dans certaines situations, vous ne voulez pas vraiment faire abstraction du moteur de base de données de 10 000 $ par CPU que vous utilisez juste au cas où vous voulez échanger sqlite3. –
Oui. Les ORM peuvent enlever beaucoup de poids à un développeur d'applications; à tout le moins, la conception avec eux à l'esprit ne devrait pas ajouter beaucoup de fardeau à la conception, et peut aider considérablement à l'avenir si vous décidez d'aller avec un ORM.
Comme d'autres l'ont mentionné; Si vous dépendez fortement de la base de données (relationnelle), les ORM ne donnent que peu et ajoutent une abstraction moins utile. Mais le plus important: voulez-vous (voulez-vous) traiter les données comme des objets ou non? Si oui, les ORM sont conçus pour cela. Si non, pourquoi s'embêter. Et vous pouvez ajouter ORM plus tard si nécessaire - peut prendre un peu plus de temps que d'avance, mais faire l'inverse (éliminer Hibernate après que ça vous gêne ...) est bien pire.
Mais il existe également des différences entre les ORM; iBatis pourrait être mieux adapté que Hibernate, par exemple (il y a d'autres questions pour ce sujet particulier).
Personnellement, je les ai trouvés (eh bien, Hibernate) pour être un puits de temps incroyable. Loin de gagner du temps, j'ai passé beaucoup trop de temps à essayer de comprendre ce qu'il fait vraiment sous les couvertures.Comme d'autres l'ont mentionné, si votre modèle de données dépasse une certaine complexité, avoir une autre couche entre vous et la base de données crée simplement plus de friction. Si votre modèle de données n'est pas si complexe, eh bien, vous n'avez pas vraiment besoin d'ORM.
I do recommande d'avoir une sorte d'abstraction pour garder SQL hors de votre code Java, mais cela peut être fait simplement avec une couche DAO et des fichiers de propriétés ou autres. Des outils comme IBATIS ou Spring JDBC peuvent également être utiles, car vous pouvez toujours écrire vos propres requêtes, et utiliser simplement le framework pour vous aider avec tout le code standard pour le transfert de données entre JDBC et vos objets Model.
PS: note amusante. Dans mon bureau, nous avons une photo encadrée de Gavin King que nous maudissons tous en effigie. "Hey, c'est votre tour pour faire face au problème Hibernate d'aujourd'hui, alors voici Gavin." :-)
C'est exactement ce que je ressens. Hibernate introduit plus de problèmes qu'elle n'en résout. JDBC avec SQL Builder est la voie à suivre dans mon opinion personnelle. Jetez un oeil dans cette lumière ORM avec SQL constructeur: http://mentabean.soliveirajr.com – TraderJoeChicago
Un ORM dissocie volontairement vos objets de travail de la base de données, créant une abstraction (inévitablement avec des fuites). Donc, vous finiriez par passer à travers le tunnel pour restaurer ce que vous avez intentionnellement éliminé.
Si une grande partie de votre application est intentionnellement implémentée dans la base de données, un ORM ajoute simplement du bruit à votre signal et atténue le signal.
Le mappage OR peut poser un problème pour votre SQL spécifique à la base de données. Cependant, certains concepts de mappage des OR sont très puissants et faciliteront l'interaction avec votre base de données. Certains de ces concepts communs à de nombreux OR-mappers sont:
Un bon outil pour votre tâche pourrait être http://jooq.sourceforge.net , qui vous permet de créer n'importe quel SQL que vous voulez (y compris les sélections imbriquées, unions, jointures complexes, alias, procédures stockées, UDTs, etc.)
Je préfère personnellement être aussi proche que possible de SQL, donc j'utiliserais iBatis , JOOQ ou MentaBean. En passant, offre une approche aussi proche que possible de SQL tout en offrant beaucoup d'aide avec le code JDBC passe-partout.
ORM: Oui pour tous les logiciels comme des entreprises, où les données sont complexes ... plusieurs niveaux, des tables, des couches ... Mais même ici un bon mélange de vues NHibernate et EF6 et base de données sont conseillés.
Non pour les applications spéciales. comme la mesure et où vous devez vraiment économiser beaucoup de données, mais sans données complexité
Avec ORM il y a plusieurs possibilités, tout dépend de ce que vous voulez.
Comme un vrai mappeur ORM Je fortement recomment NHibernate et Courant NH correspondances. Vous avez besoin de beaucoup de recherches pour assembler une belle architecture, mais alors rien ne vous gêne. Avec des compromis minimes, vous obtenez une réelle flexibilité.
EF6x (noyau est pas prêt à mon humble avis N ° de prod) est appelé un ORM, mais ce qu'il génère est plus proche d'un DAL. Il y a certaines choses que vous ne pouvez pas faire efficacement avec EF6. Encore, c'est mon outil préféré pour un modèle de lecture, tandis que je le combine avec NHibernate (où NH j'utilise pour un modèle DDD/écriture).
Maintenant à performance - c'est toujours pro et les inconvénients. Si vous approfondissez plus profondément dans l'architecture ORM (voir mon article: avoid ORM bad habits) alors vous trouverez intuitivement les moyens de le rendre plus rapide. Voici mon autre article sur la façon de rendre EF6x 5x plus rapide (au moins pour les situations de lecture): EF6.x 5x faster
Que signifie "SQL complexe, réglé à la main"? Je pensais que l'ORM pourrait gérer tout ce que vous pourriez faire en SQL. – johnny
Un ORM capable de gérer * n'importe quoi * que vous pourriez faire en SQL en particulier lorsque vous envisagez un SQL spécifique (dans ce cas, Oracle). Si vous avez besoin d'utiliser des fonctionnalités spécifiques à Oracle, vous devrez probablement écrire au moins quelques unes de vos requêtes dans SQL plutôt que dans le langage de requête d'objet de l'ORM. –
Les endroits les plus communs où j'ai dû passer devant l'ORM et écrire mon propre SQL ont été des rapports. Certains rapports peuvent devenir assez complexes, et je ne pense pas non plus qu'ORM utilise PIVOT. – Min