C'est quelque chose que je traite périodiquement avec et c'est la première fois que c'était moi qui avait besoin de condamnation. Heureusement, j'ai juste essayé, j'ai fait des efforts supplémentaires pour apprendre et merci à ce livre , support de printemps et hibernate je ne le ferai pas Démarrer un projet sans envisager JPA. Mais tout le monde n'est pas disposé à aller supplémentaire que souvent (juste dans tout ce que nous traitons, je suppose). Alors, comment et quoi dire / présenter / expliquer / argumenter au moins changer leur attitude envers Orm?
7 Réponses :
Alors, comment et quoi dire / présenter / expliquer / argument / argument au moins déplacer leur attitude envers orm?
Demandez s'ils veulent continuer à écrire le même code CRUD SQL JDBC pour chaque nouveau type d'entité, vous ajoutez à votre application.
Sans une solution ORM dans la couche de données, chaque nouvelle classe d'entités nécessite n unités de travail pour rendre cette entité disponible via la couche de données (DAOS, Code CRUD, procédures stockées, interrogations d'écriture, etc.).
Orm transforme que n en une fraction d'elle-même, en supposant que l'ajout de nouvelles entités nécessite alors d'ajouter une autre cartographie pour cette entité en métadonnées.
Un grand argument difficile à renvoyer, mais un contre-argument habituel serait «Oui, mais au-delà du crud, je ne peux pas utiliser de véritables produits de base de données, etc.
moins la chaudière et une sécurité supplémentaire. Vous pouvez enregistrer vos doigts et vos programmeurs juniors ont moins de chances d'introduire des vulnérabilités d'injection SQL que je trouve très importante.
Je pense Si, toutefois, votre base de données représente une image plus grande et que votre application est l'une des nombreuses applications qui accède aux données, à l'aide de ORM peuvent avoir des impacts négatifs potentiels sur le couplage entre votre application et la base de données et la nécessité de modifier la base de données sur temps.
Mais dans une certaine mesure, vous pouvez répondre à votre question vous-même - quelles objections avez-vous eu? Comment avez-vous été convaincu la première fois?
J'ai eu toutes les objections possibles imaginables car mon expérience était lourde sur un côté des procédures stockées, puis JDBC / Spring / EJB (PRE EJB3). Je pense que le seul argument de moi-même eu était que la nouvelle technologie ne peut pas être si grave si de nombreuses applications ont commencé à l'utiliser au cours des deux dernières années. Ensuite, j'ai commencé à me rendre compte que beaucoup de mes propres résistances proviennent d'une approche de style ancienne du développement de la base de données et de l'incapacité à relier l'Orm avec la conception de la base de données, la théorie relationnelle, l'optimisation, les meilleures pratiques. Après avoir fait un effort pour utiliser OrM avec tout cela à l'esprit, c'était une percée.
OK, je vais jouer à l'avocat du diable ici.
Les procédures stockées sont une couche d'abstraction. JPA vous oblige à connaître la structure de table sous-jacente. Procédures stockées / fonctions masque qui; Vous devez seulement connaître la procédure ou la fonction d'appeler et quel est son type de retour.
JDBC fait appel à des procédures stockées de l'appel, à l'aide de l'objet de connexion PREPARECALL Méthodes.
Les procédures stockées ajoutent également une couche de sécurité: l'application elle-même ne peut généralement pas modifier manuellement les tables, appeler uniquement les procédures qui font la modification. Le SP / SF devrait également valider les arguments qui lui sont passés.
L'inconvénient majeur avec les procédures stockées consiste à obtenir des données de remise des données ... Vous devez créer votre propre installation pour mapper des tableaux et des structures revenant à des objets Java, généralement avec un Type Carte et des objets créés de manière programmatique spéciale implémentant le < code> sqldata interface.
Puis laissez-moi jouer à l'avocat anti-diable: SP ne sont pas portables, plus difficiles à tester, au refacteur, ils font réutiliser la logique plus difficile ... Pour moi, les inconvénients l'emportent sur les avantages. Voir aussi Qui a besoin de procédures stockées, de toute façon? < / a>
L'inconvénient majeur des procédures stockées est qu'ils distribuent votre logique commerciale à travers des niveaux fondamentaux; Et les niveaux ne coopèrent pas trop bien parce que nous sommes limités à l'héritage JDBC; Le résultat final double l'effort ou la couche de fosses (qui n'est pas vraiment possible) la laissant donc incomplète et incompatible. Chaque argument sur la sécurité dans les bases de données que je peux rejeter immédiatement faire référence à des personnes aux meilleures pratiques - quelle que soit la technologie qu'ils ont l'intention d'utiliser. Mais honnêtement, je ne veux pas transformer cela en JPA vs. JDBC Discussion :-)
@Grigory: Celles-ci sont probablement les arguments que vous devrez contrer, que vous l'aimiez ou non.
Je ne voudrais pas licencier SPS. Pour les équipes lourdes sur le développement SQL, le traitement par lots, l'intégration de la base de données, elles sont indispensables. Beaucoup de Code hérité (en particulier MS-SQL) Développement multi-niveaux de base avec JDBC / ODBC sur des procédures stockées. Mais j'insisterais pour penser à eux comme un outil hérité ...
Je suppose que vous avez réellement un modèle d'objet qui est plus riche que de simples dto et pas simplement une correspondance de 1: 1 avec votre schéma relationnel. Sinon, vous ne gagnez pas l'argument.
Vous gagnez si le SQL généré par Hibernate est au moins aussi efficace que les trucs codés à la main dans les PROC stockés.
Vous perdez si les PROC stockés peuvent être optimisés pour fonctionner mieux que SQL généré par hibéré.
Vous perdez si la base de données est partagée par d'autres applications qui dépendent de la procédure stockée. Vous ne pouvez pas déplacer la logique au printemps et le niveau moyen aussi facilement.
Vous avez un meilleur cas si votre application possède la base de données.
Puisque vous utilisez déjà le printemps, cela suggère que vous avez une couche DAO qui profite de la validation du printemps. Les constitutions préparées sont déjà utilisées en dessous. L'injection SQL est donc aussi peu probable pour le printemps que pour les PROC stockés.
C'est toujours plus riche - c'est pourquoi cela s'appelle ORM (APPING). Étant donné que le modèle de domaine contient au moins une relation (de tout type), il est plus riche que le schéma relationnel.
Pas si c'est une cartographie 1: 1, ce n'est pas le cas. "TOUJOURS" est trop fort dans ce cas, surtout depuis que l'OP n'a pas dit d'une manière ou d'une autre. Et pourquoi une relation dans le modèle d'objet est-elle plus riche qu'une relation de clé étrangère entre deux tables? Je ne suis pas suivi.
laissez-moi expliquer. Les relations de base de données sont définies à l'aide de clés étrangères. Lors de la manipulation de la table unique, il y a juste des clés étrangères présentes. Lors de la manipulation d'une entité unique, il y a toujours des entités relationnelles paresseuses ou même initiées avec impatience.
Si ORM SQL n'est que 10-15% moins efficace, puis-je le rejeter? 10% diminuent-il de la performance l'emporte sur 50% de productivité? Si nous avons une différence de 50%, la bonne question sera-t-elle la bonne question à examiner le modèle et la conception de domaine de domaine ORM - il est probable que l'inefficacité des origine existe-t-elle?
@grigory - Votre explication n'a aucun sens que ce soit.
"Whatsover" est trop fort dans ce cas. Veuillez ne pas regarder le modèle de domaine entier et la base de données relationnelle en cours de comparaison. Regardez l'entité donnée et la relation correspondante (tableau) - La relation est limitée à ses données et à ses définitions de clé étrangère, tandis que l'entité comprend un graphe riche d'objets.
Les données et ses définitions de clé étrangère peuvent être au moins aussi riches en tant qu'entités, sinon ORM ne fonctionnerait pas. "Aucun sens de ce que ce soit" faisait référence à cette phrase: "Lors de la manipulation d'une entité unique, il y a toujours des entités de relation paresseuses ou même initiées avec impatience."
Bien sûr, ORM ne fonctionnerait pas si cela ne peut pas lire des données relationnelles! Allez, le point que je fais est en fait simple: le graphique des objets (contenus par une seule entité) est plus riche que la base de données relationnelle tuple. Je suppose que nous ne pouvons accepter que de désaccorder à partir de ce point.
Vous avez dit "toujours". Je suis en désaccord - relationnel peut être aussi riche que ORM si c'est 1: 1. Et si ce n'est pas en relation relationnel, mais c'est dans des objets, alors ce n'est pas persistant. Vous pouvez mapper M Tables sur N Objets, lorsque n> = m, mais les données sont identiques dans les deux cas. "RICHER" est un jugement subjectif.
La réponse à votre question est en fait assez simple et totalement indépendante de savoir si vous êtes un DBA dur-dur. Vous devez vous demander:
écrivez-vous une application centrée sur le modèle de domaine avec beaucoup de crud?
ou écrivez-vous une application relationnelle-modèle-modèle sans que beaucoup de crud?
Dans le premier cas, choisissez un orj. Dans le second cas, choisissez SQL. Si vous avez les deux dans votre application, choisissez les deux. Les deux modèles ne sont pas mutuellement exclusifs, bien que les ormes font imposent beaucoup de règles sur votre conception de l'application.
Notez que les ormes ne sont pas "la prochaine chose" dans le monde de Java. Ils sont une excellente invention à résoudre uniquement les certains problèmes (nommément crud complexe ou répétitif)
Ormes La moitié de l'occasion pour des erreurs dans une application lors des procédures stockées de l'autre côté de la possibilité d'erreurs.
S'il y a un bogue dans l'application, vous devez penser: est-ce le code ou il y a simplement quelque chose à propos de cette procédure stockée.
En outre, comment testez-vous SPS de manière isolée?
N'oubliez pas qu'un bogue dans le code et un bogue dans la base de données peuvent doubler de manière gagnante pour créer une solution de travail. Tout comme comment en mathématiques deux négatifs font un positif. Cela devient chaos, lorsque le SP est corrigé sans réparer le code, et vice-versa.
Le lien est mort. Veuillez fournir le nom dudit livre au profit des Latecomers américains.
Vient de changer pour lier à ma réponse à une autre question qui décrit le livre. Merci d'avoir souligné Lien mort.