Comment concevoir une application Web Java sans ORM et sans SQL embarqué

Question

EDIT: Titre Original: Question au sujet de l'avantage de l'utilisation d'un ORM.

Je veux utiliser un ORM pour des fins d'apprentissage et je suis d'essayer nhibernate. Je suis en utilisant le tutoriel et puis j'ai un projet réel. Je peux aller la "vieille manière" ou d'utiliser un ORM. Je ne suis pas sûr que je comprends tout à fait l'intérêt. D'un côté, je peux créer mon abstractions dans le code, tel que je peux changer mes bases de données et de la base de données indépendante. Sur l'autre, il semble que, si j'ai fait changer les colonnes de base de données, j'ai changer tout mon code.

Pourquoi n'ai-je pas de mon application sans l'ORM, de modifier ma base de données et de changer mon code, au lieu de changer ma base de données, orm, et le code? Est-ce qu'ils structure de base de données ne change pas tant que ça?

Je crois qu'il y a de réels avantages, car les Formulaires sont utilisés par de nombreuses. Je ne suis pas sûr que je l'obtenir encore.

Je vous remercie.

EDIT: Dans le tutoriel qu'ils ont beaucoup de fichiers qui sont utilisés pour faire de l'ORM de travail

http://www.hibernate.org/362.html

Dans le cas d'une demande de changement, il semble que beaucoup de travail supplémentaire juste pour dire que j'ai une "bonne" couches d'abstraction. Parce que je suis nouveau à cela, il n'a pas l'air facile à maintenir et semble de nouveau comme travail supplémentaire, pas moins.

EDIT: C'est une vieille question que je continue à revenir. Ce que je veux voir si un exemple d'une bonne conception d'une application sans un ORM et sans l'aide d'embedded SQL et sans aide .NET, LINQ-to-SQL, n'en déplaise. Je suis dans le monde Java pour le moment, et je suis perdu sur la façon de procéder. C'est une application web. Pas de Printemps, pas d'autres mondains de cadres. JSP, JSTL, EL, HTML, JavaScript, CSS, Java, Tomcat. Espérons que je n'ai rien laissé au hasard. Et oui, je sais c'est une vieille question. Il est toujours d'actualité.

Answer 1

Pourquoi, oh pourquoi, est l'industrie, de sorte attaché à cette catastrophe d'un concept? Aucune des réponses précédentes de manière adéquate les adresses @johnny préoccupations. Ils sont tous à moitié cuit à la main en agitant les justifications qui steer claire des problèmes concrets, en face de la base de données programmeurs.

@TheTXI la réponse est typique des réponses que je reçois quand vous posez la même question: la séparation des couches. Qu'est ce que ça veut dire? Pourquoi ai-je envie de séparer mes couches? Ou, plus précisément, comment peut-elle m'être utile pour créer une couche supplémentaire qui est différente de la structure relationnelle de la couche et qui pourtant est censé être une représentation canonique de la cartographie à partir de cette couche?

En outre, (@johhny's encore sans réponse point) comment est-ce à nous protéger de changement? Si les modifications de base de données, la couche ORM va presque certainement à suivre. En fait, la valeur par défaut en matière de modélisation des tables de jointure au niveau de l'objet cela rend encore pire, parce que quand la table s'accroît inévitablement certaines colonnes supplémentaires, vous n'avez pas seulement ajouter quelques champs supplémentaires dans le modèle objet, mais vous pouvez également changer sa topologie et de la force d'un tas de réécriture du code! C'est une catastrophe pour la gestion du changement et est un exemple classique de la façon dont une vision erronée de relations (en pensant qu'ils représentent des objets) tribunaux de catastrophe. Ce ne serait tout simplement pas eu lieu si vous venez de connecter la base de données relationnelle directement dans l'harmonie des notions en langage de programmation (pensez à LINQ-to-SQL, et pas de LINQ-to-EF).

La plus grande question sans réponse dans cet espace — l'éléphant dans la pièce — est: ce problème est ORM censé être des problèmes? Et ne pas dire un "objet-relationnelles, d'adaptation d'impédance". C'est juste un autre à la main en agitant fob-off. Expliquer pourquoi il y a une différence d'impédance, et pourquoi il devrait être à la base de données qui vient de la langue plutôt que de la langue va de la base de données. Mon explication est que la plupart des langages de programmation sucer à exprimer et à travailler avec des données relationnelles, mais que c'est une réalité historique qui est en train de glisser loin (LINQ-to-SQL a été le premier bébé-étape dans cette direction), pas un principe fondamental sur lequel la base de son architecture.

Il ya une raison que les Orm sont devenues tellement complexes, avec lazy-loading, la mise en cache, un nombre ahurissant de la persistance et de la sémantique de propriété, etc. Et il ya une raison que pour le pilonnant sur le clavier, ils ne parviennent toujours pas à résoudre efficacement les problèmes de base comme, "où des paires de membres partagent plus d'un groupe?" Le modèle relationnel a été conçu à une époque où le réseau et hiérarchique modèles de flambement à genoux sous le poids de ces problèmes; c'était une bouffée d'air frais. Maintenant que nous semblons tous aspirent à revenir à notre ancien bac à sable plein de chat-pipi, et nous pensons que nous avons inventé quelque chose de nouveau (tant que nous nous accrochons notre nez).

(Je m'attends à être généreusement bas-voté sur cette réponse. Mais s'il vous plaît laissez un commentaire lorsque vous le faites. Je n'ai pas l'esprit dit que je me trompe, tant que je sais pourquoi.)

EDIT: Merci @Chris pour prendre le temps de commenter. Il me donne quelques points concrets à l'adresse... (Note que bien que j'ai souvent l'adresse @Chris-dessous, je n'essaie pas de le prendre à tâche spécifique; ses réponses sont typiques de ce genre de commentaires que j'entends tout le temps au moment de discuter de ce sujet. Donc j'espère qu'il ne prend pas mes critiques comme un affront personnel; ils ne sont pas conçus de cette façon, et je n'ai vraiment apprécier le temps qu'il a fallu pour répondre.)

Tout d'abord, permettez-moi de dissiper certaines idées fausses évident dans @Chris de commentaires et de répondre.

1. Je ne préconise pas de raw SQL dans le code, pour les raisons évidentes, et certains ne sont pas si évidents (par exemple, SQL est ni l'algèbre, ni d'un calcul, ce qui rend la décomposition fonctionnelle pratiquement impossible).
2. Je ne préconise pas monolithique de la conception de l'application. Les couches sont, en général, une bonne chose.
3. Je ne préconise pas de polluer les modèles d'objet avec beaucoup de bruit sur la ligne, comme les champs, les méthodes et attributs. Franchement, cependant, c'est un strawman, depuis de domaine/objet de modèles n'existent que dans l'ORM univers. Maintenant, je sais que LINQ-to-SQL a toutes ces classes avec beaucoup de noisy bits en eux, mais ils sont juste derrière-le-scènes de la plomberie, vous n'avez pas modifier ce code, et en général, vous ne devriez même pas le regarder.

Maintenant quelques objections les objections:

1. L'affirmation que les applications peuvent être construits de façon indépendante de la base de données n'est pas fondé. En gros, les Formulaires sont à seulement canonique de la cartographie sur la couche de données (Tables de Foo et Bar deviennent des classes de Foo et Bar et d'une table de FooBar devient une sorte de torride aventure entre les classes Foo et Bar). Il n'y a pas beaucoup de marge de manœuvre dans ce travail de cartographie, de sorte que tout changement dans le modèle de données sera presque certainement besoin d'un changement correspondant au modèle de l'objet. C'est une bonne chose de mon point de vue, comme un objet qui a radicalement écartée de la base de données correspondante modèle serait rien de plus qu'un entretien supplémentaire des maux de tête pour tous les intéressés.
2. Une fois l'illusion que l'Orm engendrer de données-le modèle d'indépendance est rejetée, toutes les protestations sur les maux de couplage direct pour le modèle de données devient sans objet. Mais j'aimerais poursuivre un peu plus loin que de simplement le faire disparaître. Le couplage est une caractéristique essentielle de la conception du système. À un certain point, les décisions et les hypothèses doivent être faites. Vous ne pouvez pas programmer tout en utilisant un seul "Choses" de la table. Vous devez décider que votre domaine contient certains des concepts spécifiques et ensuite créer des schémas et code que le respect de ces concepts, de les traiter comme des citoyens de première classe, le code en dur. L'idée que les demandes doivent être indépendants de la base de données est erronée. La base de données est (ou devrait être) la plus pure représentation de l'entreprise connaissance (je sais que ce n'est pas toujours le cas, et je vais aborder ce sujet plus tard). Le couplage de cette représentation, il faudrait fournir la meilleure garantie de résilience, car un tel modèle de données ne changeront que lorsque l'entreprise elle-même subit quelques changement intrinsèque. En bref, le couplage à un schéma de base de données est une très bonne chose.
3. La superposition n'est pas une fin en soi. Il est bon parce qu'il a atteint un objectif. Les développements qui précèdent montrent que la superposition entre la base de données et l'application dans la voie de l'ORM n'est ni efficace, ni nécessaire pour atteindre le but réel de la résilience au changement. Ceci est réalisé grâce à une bonne conception de base de données.
4. @Chris affirme que la location de la base de données de dicter les choses contrecarre OO design. C'est assez vrai, mais c'est seulement intéressant si OO conception est la meilleure façon de modéliser la connaissance. L'échec quasi complet de la OODBMSs dans le marché des indices que ce n'est pas le cas. Le modèle relationnel, avec son prédicat logique de fondation, possède le même pouvoir d'expression que OO conception sans encourir la théorie des graphes complexités de OO modèles.
5. @Chris nourrissait à l'encontre du modèle relationnel au motif qu'il ne résout pas les problèmes d'aujourd'hui (d'où le mouvement NoSQL) est complètement à côté de la marque. NoSQL signifie "Pas de SQL", non, "Pas de modèle relationnel". Malheureusement, même les partisans de partisans du mouvement NoSQL semblent être tout à fait ignorant en la matière. SQL a de graves défauts, beaucoup de ce qui peut être suivie jusqu'à sa rupture radicale avec le modèle relationnel. Pour dire que nous devons abandonner le modèle relationnel, SQL suce, c'est assez flagrant à jeter le bébé avec l'eau du bain.
6. La non-utilisation d'un ORM n'est pas le triple de l'effort de construction d'une application. C'est d'un ridicule demande, et même @Chris semble se tenant l'arrière de la porte ouverte avec un compliment détourné de la codegen alternative. Codegen des outils tels que LINQ-to-SQL sqlmetal sont une solution parfaite pour n'importe qui qui n'est pas attaché à l'dogme que l'application du modèle de données doit absolument être différents à la base de données du modèle de données.

Ma propre expérience avec l'Orm a été qui ils travaillent beaucoup dans les tutoriels et causer de la douleur sans fin et de la frustration dans le monde réel. Avec LINQ-to-SQL de fixation nombre de problèmes qui ont motivé les Orm, en premier lieu, je ne vois aucune raison de me mettre à travers ce genre de torture.

Un problème majeur demeure: la culture actuelle des bases de données SQL n'offre pas significative le degré de contrôle sur la séparation des couches physiques et logiques. La cartographie à partir d'une table de trucs sur le disque est en grande partie fixe et entièrement sous le contrôle de la SQL SGBD. Ce n'était pas une partie du plan pour le modèle relationnel, qui stipule explicitement que la séparation entre les deux, et a permis la définition d'une cohérence logique de représentation de données pouvant être stockées sur le disque dans une structure très différente que ce qui était suggéré par le modèle logique. Par exemple, un système (ou dba) serait libre physiquement denormalise — pour des raisons de performances hautement normalisé modèle logique. Parce que SQL moteurs ne permettent pas cette séparation des préoccupations, il est courant de denormalise ou autrement, la torture, le modèle logique par pure nécessité. En conséquence, les modèles logiques ne peuvent pas toujours être exactement comme ils le devraient, et donc, l'idéal de l'utilisation de la base de données la plus pure représentation de la connaissance ne peut être pleinement réalisé. Dans la pratique, cependant, les concepteurs généralement s'en tenir à un canoniques de cartographie de base de données de modèle de domaine de toute façon, parce que tout le reste est tout simplement trop difficile à maintenir.

Answer 2

Dans mon expérience avec NHibernate c'est un peu comme Visual Basic: il est facile, les problèmes vraiment facile, mais il ne fait rien de plus difficile que de que vraiment difficile, voire impossible.

L'idée de base est que l'ORM évite d'avoir à écrire de code de persistance. Il y a beaucoup de répétitions dans ce code, il est donc très tentant de faire que le code générique, plutôt que spécifique à une entreprise en particulier de la couche, et de les réutiliser dans des projets. So far So good. Pour simple objet de la hiérarchie et les exigences commerciales de ce fait, il fonctionne vraiment bien. Si votre base de données change, oui, vous n'avez qu'à changer les fichiers de mapping ORM, mais c'est généralement assez simple et vous n'avez qu'à faire le changement dans un endroit beaucoup plus facile que de changer le code qui accède à la base de données.

Le problème est que tant que votre base de données et les exigences deviennent plus complexes de l'ORM trouve de plus en plus difficile de le suivre. Donc, l'ORM devient de plus en plus complexe. Il prend également des raccourcis, de faire quelques choses de façon inefficace, car il n'est tout simplement pas assez intelligent pour comprendre comment le faire de manière efficace dans tous les cas. Ce qui est plus, car l'idée est qu'il fonctionne de manière transparente, souvent, vous ne pouvez pas voir ces problèmes de performance jusqu'à ce qu'ils deviennent assez mauvais pour affecter l'expérience utilisateur. Un problème connexe est que les bugs sont beaucoup plus difficiles à trouver, parce que vous ne savez pas ce qui se passe à l'intérieur de l'ORM, sauf si vous le déboguer. (Oui, j'ai eu à l'étape par NHibernate code et il n'est pas de pique-nique!)

Vous commencez donc en contournant l'ORM pour certaines choses, et d'utiliser SQL directement à la place. Bien sûr, vous avez alors à faire que le code du travail le code qui n' utiliser l'ORM, qui est plus de travail. Vous finissez par écrire le code pour charger et enregistrer des objets à la main et en quelque sorte de travail que dans l'ORM code. Finalement, vous commencer à se demander si l'ORM est de créer plus de travail pour vous que c'est de sauver, de ne pas mentionner la performance et de la chasse au bug des maux de tête.

Donc, si vous écrivez une application très simple, le genre que vous trouverez dans un tutoriel, ORM va faire un bon travail. Si c'est plus complexe que ça, puis je pense que c'est pas la peine. Bien sûr, pour une application simple de la quantité absolue de gain de temps sera petit. Ma conclusion: il suffit de ne pas s'embêter avec l'ORM. L'ORM est le chemin qui mène au côté obscur.

Answer 3

Avant la lecture de cet je me suis souvent demandé si d'autres vraiment pris la peine de comprendre l'impact d'un outil ORM a sur un projet. @Evgeny, @Marcelo Cantos, et @Jimmy B de repos.

En bref, ils sont morts sur la plupart des questions qui entourent outils ORM. Il ya seulement un couple soit qu'ils n'ont pas couvertes ou que vous n'avez pas assez couvert.

Tout d'abord, l'utilisation d'un ORM ne signifie pas moins de code. Cela pourrait signifier moins de SQL, mais il a certainement ne signifie pas moins de code. Le long de ces lignes, l'outil de code généré peut être erronée. Pire, pour compenser le mauvais code généré est un exercice de frustration.

Deuxièmement, les outils ORM ne signifie PAS que vous n'avez pas à comprendre SQL. Pour mettre cela d'une autre façon, vous devez connaître SQL pour être efficace, un programmeur (il y a des exceptions comme l'embedded gars). Les requêtes (type et nombre) émis par ces outils ne sont tout simplement pas assez bon à partir d'une prestation ou d'un point de vue des ressources. Si vous avez déjà connaître SQL, pourquoi l'anse-vous?

Troisièmement, les outils ORM ne PAS gagner du temps. Il vous permettra de passer autant (si pas plus) le temps de battre votre ORM outil de choix dans la soumission afin de prendre soin de n'importe quelle application de taille décente. Pour ajouter l'insulte à la blessure, lorsque vous avez terminé, vous verrez que la qualité des requêtes sont généralement pire que si vous l'aviez fait vous-même. Point est ORM = plus de temps consacré au projet, le pire résultat.

Quatrièmement, SGBD indépendance est généralement une perte de temps. La plupart des applications utilisent exactement un SGBD plus c'est la vie; si c'est Oracle, SQL server, MySql, que ce soit. L'application sera beaucoup mieux, il est capable de tirer parti des fonctionnalités des SGBD fournit. En cours de SGBD agnostique signifie que vous devrez vous limiter à sous par des requêtes.

Cinquième, tout n'a pas à être un objet. C'est une chose importante à noter. Il nous est souvent demandé de montrer un ensemble particulier de données sur une page. Plus souvent qu'autrement, cela signifie se joindre à des données provenant de deux ou plusieurs tables. Si votre application est nécessaire de créer et d'instancier tous ces objets, il suffit d'afficher certaines données? Ou êtes-vous mieux l'exécution d'une requête et d'émettre les données directement à l'écran/navigateur dans le format de votre choix?

L'ORM est d'ajouter BEAUCOUP de frais généraux à même les choses les plus simples. La plupart des ORM volonté de générer de multiples requêtes sql pour effectuer une simple mise à JOUR sur une table.

Sixième, et la question la plus importante dans mon esprit: ORM diminution de la sécurité de votre système. Bien sûr, vous pouvez utiliser l'ORM avec s'procs; mais la plupart des gens ne le font pas. Presque toutes les applications que j'ai vu qui a mobilisé un ORM exposé de la base de telle manière que si le site est fissuré l'ensemble de la base de données peut être facilement tués ou volés. Outils ORM générer du SQL à la volée. Cela signifie qu'ils doivent avoir directement accès à la table. Cela signifie que si votre application est compromise, le pirate aura directement accès à la table. Cela signifie que vous avez effectivement enlevé au moins une couche de sécurité à partir de votre application.

Answer 4

Je me rends compte que cette question a été posté il y a longtemps, mais je me suis demandé la même chose que johnny. J'ai vu Hibernate utilisé sur plusieurs grands projets, par des gens intelligents, et dans tous les cas, ça a été un désastre total. Dans mon expérience, le plus compliqué et de la performance a une incidence sur la zone de la plupart des applications d'entreprise est entre la couche métier et la couche de base de données. C'est en partie pourquoi nous ajoutons une couche d'accès aux données pour essayer de résumer la base de données des interactions en parties gérables.

Le plus grand des arguments que j'ai vu à l'utilisation de l'ORM et qu'ils sont "réduire code écrit à la main" et de fournir une couche d'abstraction qui sépare la logique métier de l'accès aux données. J'affirme qu'aucune de ces sont remplies dans la pratique, sauf dans des cas très simples.

Pour faire Hibernate (et la plupart des autres outils ORM) de travail, soit de créer un fichier de mapping hibernate qui tous les documents de la base de données et des interactions entre les objets, ou nous utilisons les annotations du document le même type de relations. Dans un cas, nous avons déménagé notre code d'un fichier de configuration xml qui est plus difficile à tester, mais non moins complexe. Dans l'autre, nous distribuons la logique de la façon d'interagir avec la base de données sur le modèle de domaine. Le point est, alors que nous avons écrit moins réelle, "code", code de passer à des fichiers de configuration ou des annotations != "moins de code". Il se déplace simplement la complexité du code, où l'on peut contrôler directement et de réduire, à un outil tiers avec beaucoup moins de contrôle.

L'ORM de la couche d'abstraction qui est censé séparer les affaires du domaine/de la couche de la couche de base de données tend à avoir des effets plus subtils qui s'opposent à cette "séparation". Combien de projets avez-vous vu où l'ORM couche affecte la conception du modèle d'objet et/ou de la base de données d'une manière qui serait considéré comme moins que l'idéal? Pour utiliser une mauvaise analogie physique, supposons que votre couche de gestion, ORM couche et couche de base de données tous ont une masse. La simple existence de la couche ORM entre les autres tend à exercer une force que les changements et les croisements de toutes les autres couches. Avez-vous eu à introduire une clé primaire de l'objet qui ne correspond pas exactement à votre modèle d'affaires, car la couche ORM besoin? Avez-vous dû adapter votre structure de base de données pour accueillir un particulièrement complexe de l'objet graphique modèle, car l'outil ORM peut pas gérer autrement? Poussé à l'extrême, la présence de la couche ORM peut déformer l'ensemble de la perspective de la base de données des interactions de travail. Au lieu d'une couche de service qui gère la persistance des objets graphiques, il peut se résumer à la création individuelle couche d'accès aux données des objets pour chaque domaine d'objets, comme si ils vivent dans l'isolement. J'ai vu tous ces scénarios, à des degrés divers. C'est peut-être l'inexpérience avec l'ORM d'outils. C'est peut-être une mauvaise structure de base de données. J'en doute. Tout ce que j'ai vu des points à l'ORM solution insuffisante.

Si vous acceptez mon affirmation que la couche d'accès aux données est celui de la complexité, très sujettes à des goulots d'étranglement des performances, pourquoi devrais-je envisager d'ajouter dans un outil qui ne veut pas atteindre ses objectifs, de moins de code et de la séparation, et dans le même temps, ce qui nuirait à la structure des autres couches de mon application?

Answer 5

J'ai répondu à fond pour la réponse par @Marcelo Cantos cependant, je vous summurize les principaux avantages de l'utilisation d'un ORM.

L'Ignorance de la persistance (PI) et le Domaine de Lecteur de Design (DDD)

Un ORM se prête parfaitement à la fois de ces modèles de conception. Pour corriger orientée objet design, vous travaillerez avec hiérarchique et polymorphe des objets pour exprimer la façon dont les flux de données à l'intérieur de votre application. Avec une bonne conception, vous aurez souvent lutter pour des objets POCO (plain old C/C# objets, j'ai vu d'autres définitions de ce mot), parce que si j'ai une Personne qui a une Liste j'aurais juste que. Je ne devrais pas avoir un DataTable de personnes et d'une Table de données d'adresses que j'ai un peu de force pour travailler avec mon application. Avec qui je n'aurais pas besoin de mettre des tonnes de base de données logique spécifique pour mes objets, pourquoi le champ de Prénom de ma personne a besoin pour être quelque chose comme des [ColumnName("First_Name")] [Length(255)] [DataType(Types.Nvarchar)] ou de toute autre assortiment de fou attributs ou d'un code qui définit le nombre de base de données existe forcé dans mon domaine de la conception?

Moins De Code Écrit

Il y a une réduction substantielle du nombre de lignes de code écrites lorsque vous retirez le besoin d'écrire un Select, Insert, Update et Delete pour chaque objet dans votre application pour l'enregistrer dans la base de données. Cela vous laisse avec seulement la nécessité d'écrire des requêtes qui signifie quelque chose. Aussi de nombreux Formulaires (comme NHibernate) comprendra une langue qui est en couches sur le dessus de SQL qui est de plus en plus définie à interagir avec et peut-être moins du point de vue syntaxique rempli de cerceaux.

Le temps de cette montre jusqu'à ce maximum est une application qui a un UserTable qui est lié à chaque objet et pour une raison quelconque, vous devez modifier la clé primaire nom ou le type. À ce stade, vous aurez éventuellement besoin de modifier chaque procédure stockée dans la base de données avec une mise en œuvre correctement ORM solution, vous aurez seulement besoin de modifier un peu la configuration des mappages (ou éventuellement aucune), et c'est fait.