Comment puis-je concevoir une application Web Java sans ORM et sans SQL intégré

EDIT: Titre original: Question sur l’intérêt d’utiliser un ORM.

Je veux utiliser un ORM à des fins d’apprentissage et essayer le nibernate. J’utilise le tutoriel et j’ai un vrai projet. Je peux aller à l’ancienne ou utiliser un ORM. Je ne suis pas sûr de bien comprendre le bénéfice. D’une part, je peux créer mes abstractions en code de telle sorte que je puisse modifier mes bases de données et être indépendant de la firebase database. D’autre part, il me semble que si je change réellement les colonnes de la firebase database, je dois changer tout mon code.

Pourquoi n’aurais-je pas mon application sans ORM, changer ma firebase database et modifier mon code, au lieu de modifier ma firebase database, orm et mon code? Est-ce que leur structure de firebase database ne change pas beaucoup?

Je crois qu’il y a de réels avantages car les ORM sont utilisés par tant de personnes. Je ne suis juste pas sûr de l’avoir encore.

Je vous remercie.

EDIT: Dans le tutoriel, ils ont beaucoup de fichiers qui sont utilisés pour faire fonctionner l’ORM

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

En cas de changement d’application, il semble que beaucoup de travail supplémentaire soit nécessaire pour dire que j’ai des couches d’abstraction “correctes”. Parce que je suis nouveau sur le marché, cela ne semble pas facile à entretenir et, encore une fois, cela semble être un travail supplémentaire, pas moins.

EDIT: C’est une vieille question à laquelle je reviens sans cesse. Qu’est-ce que je veux voir si un exemple de conception correcte d’une application sans ORM et sans utiliser Embedded SQL et sans utiliser .NET LINQ-to-SQL, sans infraction. Je suis dans le monde Java en ce moment et je suis perdu sur la façon de procéder. C’est une application web. Pas de spring, pas d’autres frameworks mondains. JSP, JSTL, EL, HTML, JavaScript, CSS, Java, Tomcat. J’espère que je n’ai rien laissé de côté. Et oui, je sais que c’est une vieille question. C’est toujours pertinent.

Pourquoi, oh pourquoi, l’indussortinge est-elle si attachée à ce désastre d’un concept? Aucune des réponses précédentes ne répond adéquatement aux préoccupations de @ johnny. Ce sont tous des justifications à la main mal entretenues qui évitent les problèmes concrets auxquels sont confrontés les programmeurs de bases de données.

La réponse de TheTXI est typique des réponses que j’obtiens en posant la même question: la séparation des couches. Qu’est-ce que c’est censé vouloir dire? Pourquoi est-ce que je veux séparer mes calques? Ou, plus précisément, comment cela me profite-t-il de créer une couche supplémentaire différente de la couche relationnelle et pourtant supposée être une cartographie canonique de cette couche?

En outre, (@ johhny encore sans réponse) comment cela nous protège-t-il du changement? Si la firebase database change, la couche ORM devra certainement suivre. En fait, la pratique par défaut de ne pas modéliser les tables de jointure au niveau de l’object ne fait qu’empirer la situation, car lorsque la table produit inévitablement des colonnes supplémentaires, non seulement vous ajoutez des champs supplémentaires, mais vous modifiez également sa topologie et sa force. un tas de code réécrit! Ceci est un désastre pour la gestion du changement et est un exemple classique de la façon dont une vision erronée des relations (en pensant qu’ils représentent des objects) des sortingbunaux désastreux. Cela ne se serait tout simplement pas produit si vous aviez simplement mappé la firebase database relationnelle directement dans des notions conformes dans le langage de programmation (pensez à LINQ-to-SQL, et non à LINQ-to-EF).

La plus grande question sans réponse dans cet espace – l’éléphant dans la pièce – est la suivante: quel est le problème que l’ORM est censé résoudre? Et ne dites pas “inadéquation impédance relationnelle-object”. C’est juste un autre fob-off agitant la main. Expliquez pourquoi il y a une incompatibilité d’impédance et pourquoi cela devrait être la firebase database utilisée dans la langue plutôt que la langue utilisée dans la firebase database. Mon explication est que la plupart des langages de programmation craignent d’exprimer et de travailler avec des données relationnelles, mais qu’il s’agit d’une réalité historique qui commence à disparaître (LINQ-to-SQL a été le premier pas dans cette direction), pas un principe fondamental sur lequel baser l’architecture sonore.

Il y a une raison pour laquelle les ORM sont devenus si complexes, avec le chargement différé, la mise en cache, un tableau déconcertant de persistance et de sémantique de propriété, etc. Et il y a une raison pour laquelle tous ces problèmes des problèmes tels que “Quelles sont les paires de membres qui partagent plus d’un groupe?” Le modèle relationnel a été conçu à une époque où les modèles de réseau et les modèles hiérarchiques étaient agenouillés sous le poids de tels problèmes. C’était une respiration d’air fraîche. Maintenant, nous avons tous envie de retourner dans notre ancien bac à sable plein de cat-pee, et nous pensons avoir inventé quelque chose de nouveau (du moment que nous nous tenons le nez).

(Je m’attends vraiment à être libéré de cette réponse. Mais laissez-moi un commentaire quand vous le faites. Cela ne me dérange pas de me dire que je me trompe, du moment que je sais pourquoi.)

EDIT: Merci @Chris d’avoir pris le temps de commenter. Cela me donne des points concrets à aborder… (Notez que bien que je parle souvent de @Chris ci-dessous, je n’essaie pas de le prendre spécifiquement en charge; ses réponses sont typiques des types de commentaires que j’entends tout le J’espère donc qu’il ne prend pas mes critiques comme un affront personnel, elles ne le sont pas de cette façon et j’apprécie sincèrement le temps qu’il a pris pour y répondre.

Tout d’abord, laissez-moi clarifier certaines idées fausses évidentes dans les commentaires et la réponse de @ Chris.

  1. Je ne préconise pas le SQL brut dans le code, pour toutes les raisons évidentes, et certaines moins évidentes (par exemple, SQL n’est ni une algèbre ni un calcul, ce qui rend la décomposition fonctionnelle pratiquement impossible).
  2. Je ne préconise pas la conception d’applications monolithiques. Les couches sont en général une bonne chose.
  3. Je ne préconise pas les modèles d’object polluants avec beaucoup de bruits de ligne tels que les champs spéciaux, les méthodes et les atsortingbuts. Franchement, cependant, il s’agit d’un modèle simple, puisque les modèles de domaine / object n’existent que dans l’univers ORM. Maintenant, je sais que LINQ-to-SQL a toutes ces classes avec beaucoup de bits bruyants, mais elles sont juste en coulisse; vous n’éditez pas ce code et vous ne devriez même pas le regarder.

Maintenant, quelques objections aux objections:

  1. L’affirmation selon laquelle les applications peuvent être créées indépendamment de la firebase database n’est pas fondée. En gros, les ORM ne sont qu’un mappage canonique sur la couche de données (les tables Foo et Bar deviennent les classes Foo et Bar, et la table FooBar devient une sorte d’affaire torride entre les classes Foo et Bar). Il n’y a pas beaucoup de marge de manœuvre dans ce mappage et toute modification du modèle de données nécessitera certainement une modification correspondante du modèle d’object. C’est une bonne chose à mon avis, car un object qui diffère radicalement du modèle de firebase database correspondant ne serait rien de plus qu’un problème supplémentaire de maintenance pour toutes les personnes concernées.
  2. Une fois que l’illusion que les ORM engendrent l’indépendance du modèle de données est rejetée, toutes les protestations concernant les méfaits du couplage direct avec le modèle de données deviennent sans object. Mais je voudrais aller un peu plus loin que de simplement le rejeter. Le couplage est une caractéristique essentielle de la conception du système. À un moment donné, les décisions et les hypothèses doivent être sockets. Vous ne pouvez pas tout programmer en utilisant un seul tableau “Things”. Vous devez décider que votre domaine contient certains concepts spécifiques, puis créer des schémas et du code qui respectent ces concepts, les traiter comme des citoyens de premier ordre, les coder en dur. L’idée que les applications doivent être indépendantes de la firebase database est erronée. La firebase database est (ou devrait être) la représentation la plus pure des connaissances d’une entreprise (je sais que ce n’est pas toujours le cas et je vais y répondre plus tard). Le couplage avec cette représentation devrait constituer la meilleure garantie de résilience, car un tel modèle de données ne changera que lorsque l’entreprise elle-même subira des changements insortingnsèques. En résumé, le couplage à un schéma de firebase database bien conçu est une très bonne chose.
  3. La superposition n’est pas une fin en soi. C’est bien parce que cela permet d’atteindre un objective précis. Les points précédents montrent que la superposition entre la firebase database et l’application, comme le fait l’ORM, n’est ni efficace ni nécessaire pour atteindre le véritable objective de la résilience au changement. Ceci est réalisé grâce à une bonne conception de la firebase database.
  4. @Chris affirme que laisser la firebase database dicter des choses contredit la conception OO. C’est assez vrai, mais ce n’est intéressant que si la conception OO est la meilleure façon de modéliser les connaissances. L’échec presque complet des OODBMS sur le marché suggère que ce n’est pas le cas. Le modèle relationnel, avec sa base prédicat-logique, possède le même pouvoir expressif que la conception OO sans subir les complexités de la théorie des graphes des modèles OO.
  5. @ Les objections de Chris à l’encontre du modèle relationnel au motif qu’il ne résout pas les problèmes actuels (d’où le mouvement NoSQL) sont complètement hors de propos. NoSQL signifie “Pas de SQL” et non “Pas de modèle relationnel”. Malheureusement, même les partisans du mouvement NoSQL semblent être complètement désemparés à cet égard. SQL présente des défauts profonds, dont beaucoup peuvent être atsortingbués à son départ radical du modèle relationnel. Dire que nous devrions abandonner le modèle relationnel, car SQL est nul, est un cas assez flagrant de jeter le bébé avec l’eau du bain.
  6. Le fait de ne pas utiliser un ORM ne sortingple pas l’effort de création d’une application. Ceci est une affirmation ridicule, et même @Chris semble tenir la porte arrière ouverte avec un complément à l’alternative codégen. Les outils Codegen tels que sqlmetal de LINQ-to-SQL sont une solution parfaite pour quiconque n’est pas attaché au dogme selon lequel le modèle de données de l’application doit absolument être différent du modèle de données de la firebase database.

Ma propre expérience avec les ORM est qu’ils fonctionnent très bien dans les didacticiels et causent une douleur et une frustration sans fin dans le monde réel. Avec LINQ-to-SQL qui corrige un grand nombre des problèmes qui ont motivé les ORM, je ne vois aucune raison de me soumettre à ce type de torture.

Un problème majeur demeure: la firebase database SQL actuelle n’offre aucun degré de contrôle significatif sur la séparation des couches physiques et logiques. Le mappage d’une table à un object sur le disque est en grande partie fixe et entièrement sous le contrôle du SGBD SQL. Cela ne faisait pas partie du plan du modèle relationnel, qui séparait explicitement les deux, et permettait de définir une représentation logique cohérente des données pouvant être stockées sur disque dans une structure complètement différente de celle suggérée par le modèle logique. Par exemple, un système (ou dba) serait libre de dénormaliser physiquement – pour des raisons de performances – un modèle logique hautement normalisé. Étant donné que les moteurs SQL ne permettent pas cette séparation des préoccupations, il est courant de dénormaliser ou de torturer le modèle logique par simple nécessité. Par conséquent, les modèles logiques ne peuvent pas toujours être exactement comme ils le devraient, et l’idéal d’utiliser la firebase database comme représentation la plus pure des connaissances ne peut donc pas être pleinement réalisé. En pratique, cependant, les concepteurs s’en tiennent de toute façon à un mappage canonique entre la firebase database et le modèle de domaine, car tout autre élément est trop pénible à gérer.

Dans mon expérience avec NHibernate, c’est un peu comme Visual Basic: il facilite vraiment les problèmes simples, mais cela rend tout ce qui est vraiment difficile, voire impossible.

L’idée de base est que ORM évite d’avoir à écrire du code de persistance. Il y a beaucoup de duplication dans ce type de code, il est donc très tentant de rendre ce code générique, plutôt que spécifique à une couche métier particulière, et de le réutiliser dans les projets. Jusqu’ici tout va bien. Pour les hiérarchies d’object simples et les exigences métier, cela fonctionne vraiment bien. Si votre firebase database change, oui, vous devez modifier les fichiers de mappage ORM, mais cela est généralement assez simple et il vous suffit d’apporter le changement au même endroit – beaucoup plus facile que de changer le code qui accède à la firebase database.

Le problème est que, comme votre firebase database et vos exigences deviennent plus complexes, l’ORM a de plus en plus de mal à suivre. Ainsi, l’ORM devient de plus en plus complexe. Cela prend également des raccourcis, faisant certaines choses de manière inefficace, car ce n’est pas assez intelligent pour comprendre comment le faire efficacement dans tous les cas. Qui plus est, l’idée même étant que cela fonctionne de manière transparente, vous ne pouvez souvent pas voir ces problèmes de performances jusqu’à ce qu’ils deviennent suffisamment mauvais pour affecter l’expérience utilisateur. Un problème connexe est que les bogues sont beaucoup plus difficiles à trouver, car vous ne savez pas ce qui se passe à l’intérieur de l’ORM, sauf si vous le déboguez. (Oui, j’ai dû parcourir le code NHibernate et ce n’est pas un pique-nique!)

Vous commencez donc à contourner l’ORM pour certaines choses et à utiliser SQL directement. Bien sûr, vous devez ensuite faire en sorte que ce code fonctionne avec le code qui utilise l’ORM, ce qui est plus compliqué. Vous finissez par écrire du code pour charger et enregistrer des objects manuellement et pour que cela fonctionne en quelque sorte dans le code ORM. Finalement, vous commencez à vous demander si l’ORM crée plus de travail pour vous que de le sauver, sans parler des maux de tête liés à la performance et à la recherche de bogues.

Donc, si vous écrivez une application très simple, du type que vous trouvez dans un tutoriel, ORM fera du bon travail. Si c’est plus complexe que cela, je pense que ça ne vaut pas la peine. Bien entendu, pour une application simple, le temps absolu économisé sera également réduit. Ma conclusion: ne vous embêtez pas avec ORM. ORM est le chemin qui mène au côté obscur.

Avant de lire ceci, je me suis souvent demandé si d’autres personnes avaient vraiment pris la peine de comprendre l’impact d’un outil ORM sur un projet. @Evgeny, @Marcelo Cantos et @Jimmy B ont mis cela de côté.

En bref, ils sont à court de la plupart des problèmes qui entourent les outils ORM. Il n’y a qu’un couple qu’ils n’ont pas couvert ou n’ont pas suffisamment couvert.

Tout d’abord, l’utilisation d’un ORM ne signifie pas moins de code. Cela pourrait signifier moins de SQL, mais cela ne signifie certainement pas moins de code. Dans ce sens, le code généré par l’outil peut être erroné. Pire encore, la compensation du code généré de manière incorrecte est un exercice de frustration.

Deuxièmement, les outils ORM ne signifient PAS que vous n’avez pas à comprendre le langage SQL. En d’autres termes, vous devez connaître SQL pour être un programmeur efficace (il y a des exceptions comme les types intégrés). Les requêtes (à la fois de type et de nombre) émises par ces outils ne sont tout simplement pas assez bonnes du sharepoint vue des performances ou des ressources. Si vous devez déjà connaître SQL, pourquoi vous enchaîner?

Troisièmement, les outils ORM ne permettent pas de gagner du temps. Vous passerez autant de temps (si pas plus) à battre votre outil de choix ORM pour vous soumettre à toute application de taille décente. Pour append l’insulte à la blessure, vous verrez que la qualité des requêtes est généralement pire que si vous l’aviez fait vous-même. Le point est ORM = plus de temps passé sur le projet, pire résultat.

Quasortingèmement, l’indépendance du SGBD est généralement une perte de temps. La plupart des applications utiliseront exactement un seul SGBD au cours de sa vie. que ce soit Oracle, SQL Server, MySQL, peu importe. L’application sera beaucoup mieux si elle est capable de tirer parti des fonctionnalités du SGBD. Être agnostique en termes de SGBD signifie que vous devrez vous limiter aux requêtes secondaires.

Cinquièmement, tout ne doit pas être un object. C’est une chose importante à noter. On nous demande souvent de montrer un ensemble particulier de données sur une page. Plus souvent qu’autrement, cela signifie joindre des données de deux ou plusieurs tables. Votre application doit-elle créer et instancier tous ces objects uniquement pour afficher certaines données? Ou préférez-vous simplement exécuter une requête et émettre les données directement sur l’écran / le navigateur dans le format de votre choix?

Les ORM ajoutent BEAUCOUP de surcharge aux choses les plus simples. La plupart des ORM généreront plusieurs requêtes SQL pour effectuer même une simple mise à jour sur une table.

Sixièmement, et le plus important dans mon esprit: les ORM réduisent votre sécurité. Bien sûr, vous pouvez utiliser les ORM avec s’procs; mais la plupart des gens ne le font pas. Presque toutes les applications que j’ai vues qui ont utilisé un ORM ont exposé la firebase database de telle manière que si le site est fissuré, la firebase database entière peut être facilement détruite ou volée. Les outils ORM génèrent du SQL à la volée. Cela signifie qu’ils ont besoin d’un access direct à la table. Cela signifie que si votre application est compromise, le pirate aura un access direct à la table. Cela signifie que vous avez supprimé au moins une couche de sécurité de votre application.

Je me rends compte que cette question a été publiée il y a quelque temps, mais je me suis demandé la même chose que Johnny. J’ai vu Hibernate utiliser plusieurs grands projets de personnes intelligentes et, dans tous les cas, c’était un désastre absolu. Selon mon expérience, la zone la plus complexe et la plus impactante sur le plan des performances de la plupart des applications d’entreprise se situe entre la couche de gestion et la couche de firebase database. Cela fait partie de la raison pour laquelle nous ajoutons une couche d’access aux données pour essayer d’encapsuler les interactions de la firebase database dans des blocs gérables.

Les arguments les plus importants que j’ai vus utiliser ORM sont qu’ils «réduisent le code écrit à la main» et fournissent une couche d’abstraction qui sépare la logique métier de l’access aux données. J’affirme qu’aucun d’eux n’est vrai dans la pratique, sauf dans des cas très simples.

Pour faire fonctionner Hibernate (et la plupart des autres outils ORM), nous créons un fichier de mappage d’hibernation qui documente toutes les interactions entre la firebase database et les objects, ou nous utilisons des annotations pour documenter les mêmes relations. Dans un cas, nous avons déplacé notre code dans un fichier de configuration xml plus difficile à tester, mais pas moins complexe. Dans l’autre, nous répartissons la logique d’interaction avec la firebase database sur l’ensemble du modèle de domaine. Le point est, alors que nous avons écrit moins de “code” moins réel, en déplaçant le code vers des fichiers de configuration ou des annotations! = “Less code”. Il déplace simplement la complexité du code, où nous pouvons le contrôler directement et l’atténuer, à un outil tiers avec beaucoup moins de contrôle.

La couche d’abstraction ORM censée séparer la couche métier / domaine de la couche firebase database a tendance à avoir des effets plus subtils qui contrecarrent cette “séparation”. Combien de projets avez-vous vus où la couche ORM affecte la conception du modèle d’object et / ou de la firebase database d’une manière qui ne serait pas idéale? Pour utiliser une analogie physique médiocre, supposez que votre couche de gestion, votre couche ORM et la couche de firebase database ont toutes une masse. La simple existence de la couche ORM entre les autres tend à exercer une force qui change et déforme les autres couches. Avez-vous dû introduire un object clé primaire qui ne correspond pas tout à fait à votre modèle d’entreprise, car la couche ORM en avait besoin? Avez-vous dû ajuster la structure de votre firebase database pour l’adapter à un modèle de graphique d’object particulièrement complexe, car l’outil ORM ne peut pas le gérer autrement? Pris à l’extrême, la présence de la couche ORM peut fausser toute la perspective du fonctionnement des interactions avec la firebase database. Au lieu d’une couche de service qui gère les graphes d’objects persistants, elle peut créer des objects de couche d’access aux données individuels pour chaque object du domaine, comme s’ils vivaient isolément. J’ai vu tous ces scénarios à des degrés divers. C’est peut-être une inexpérience avec les outils ORM. C’est peut-être une mauvaise structure de firebase database. J’en doute. Tout ce que j’ai vu montre que la solution ORM est inadéquate.

Si vous acceptez mon affirmation selon laquelle la couche d’access aux données est complexe, très sujette aux goulots d’étranglement, pourquoi devrais-je envisager d’append un outil qui n’atteint pas ses objectives de code et de séparation, tout en affectant négativement structure des autres couches de mon application?

J’ai répondu à la réponse par @Marcelo Cantos, mais je vais résumer les principaux avantages de l’utilisation d’un ORM.

Ignorance de persistance (PI) et conception de lecteur de domaine (DDD)

Un ORM se prête parfaitement à ces deux modèles de conception globaux. Pour une conception orientée object correcte, vous travaillerez avec des objects hiérarchiques et polymorphes pour exprimer comment les données circulent dans votre application. Avec un bon design, vous allez souvent chercher des objects POCO (des vieux objects C / C #, j’ai vu d’autres définitions de ce mot) parce que si j’ai une personne qui a une liste, je devrais avoir ça. Je ne devrais pas avoir un DataTable de personnes et un DataTable d’adresses que je force en quelque sorte à travailler avec mon application. Parallèlement à cela, je ne devrais pas avoir à relier des tonnes de logique spécifique à la firebase database à mes objects. Pourquoi le champ FirstName de ma personne devrait-il avoir quelque chose comme [ColumnName("First_Name")] [Length(255)] [DataType(Types.Nvarchar)] ou tout autre assortiment d’atsortingbuts ou de code fou définissant le nombre de bases de données forcées dans la conception de mon domaine?

Code moins écrit à la main

Il y a une réduction substantielle du nombre de lignes de code écrites lorsque vous supprimez le besoin d’écrire une instruction Select, Insert, Update et Delete pour chaque object de votre application afin de l’enregistrer dans la firebase database. Cela ne vous laisse que le besoin d’écrire des requêtes qui signifient quelque chose. De plus, de nombreux ORM (comme NHibernate) incluront un langage superposé à SQL, qui est plus défini pour interagir avec et peut être moins syntaxiquement rempli de cerceaux.

Le temps que cela affiche est considéré comme une application ayant un UserTable lié à chaque object et pour une raison quelconque, vous devez changer le nom ou le type de la clé primaire. À ce stade, vous devrez éventuellement modifier chaque procédure stockée dans la firebase database où, avec une solution ORM correctement implémentée, vous ne devrez modifier que quelques mappages de configuration (ou éventuellement aucun) et c’est fait.

L’avantage de base de l’utilisation des outils ORM est de faciliter la séparation de la logique métier de l’access aux données dans une application multicouche. Si vous parvenez à créer une couche d’access aux données qui réagit aux modifications de la firebase database (en modifiant votre mappage), le code global doit être moins complet lorsque vous apportez des modifications.

La séparation des couches est généralement l’objective des applications à trois niveaux ou à plusieurs niveaux, et ORM est une bonne méthode pour y parvenir.

Pilote primaire: moins de code global à gérer / maintenir

La question à laquelle je n’ai vu personne est de savoir quel problème ou quels problèmes les ORM sont censés résoudre. Le problème que les ORM sont censés résoudre concerne la déconnexion entre le code côté application et la firebase database et le temps que les développeurs consacrent aux problèmes de firebase database. La déconnexion entre la firebase database et le code de l’application fait référence à l’exécution de l’application pour se rendre compte que le code écrit est référencé sur une colonne non valide. Les ORM sont censés combler cette lacune, créant ainsi un modèle dans lequel la firebase database, l’application et les données se déplacent ensemble; Je comstack je sais que le code est désynchronisé (à condition que je garde mon modèle à jour).

J’ai utilisé 3 ORM différents (EF, LINQ to SQL et N-Hibernate), sur des projets de taille variée allant des petites et grandes applications d’entreprise. De plus, je ne suis pas étranger à le faire avec ADO.NET; DataReaders et mappage vers des classes, DataSets et divers outils de génération. J’ai vu de bonnes et de mauvaises implémentations dans les 3 ORM différents et sans méthode ORM. La majorité des problèmes que j’ai vus remontent aux anti- modèles et ne comprennent pas les limites d’un ORM particulier. L’article suivant ( Anti-Patterns à éviter dans les applications N-Tier ) met en évidence un bon nombre de ces anti-patterns. Même les meilleurs architectes de logiciels, développeurs et seulement des personnes intelligentes ont participé à leur part d’Anti-Patterns avant de découvrir un modèle de conception et / ou la valeur de certains principes de conception qui ont résolu le problème créé par l’Anti-Pattern.

Ne pas connaître votre outil est un autre problème car c’est là que les problèmes de performances entrent en jeu. Il est clair que beaucoup ne sont pas sûrs des différences de performances entre les procédures SQL dynamics et les procédures stockées. Eh bien, le verdict est en vigueur et les commandes dynamics se sont avérées tout aussi efficaces que leurs homologues de procédures stockées. Les deux ont des avantages et des inconvénients. La clé est de savoir ce qu’ils sont et de choisir le choix approprié pour la situation.

Si tout ce que j’obtiens de mon ORM est de me sauver du besoin de maintenir les procédures stockées, cela me suffit.

Cependant, il y a beaucoup plus dans le fait qu’un ORM nous permet de nous libérer des schémas de bases de données de sockets en otages imposés à la conception de notre code. Les choses sont beaucoup plus simples quand je peux modéliser mon code exactement comme dans le monde réel, et je peux toujours le faire avec un (bon) ORM qui aide (et cache) le mappage d’une firebase database signifie quelque chose et ne vous souciez pas du code redondant comme celui-ci partout:

 using (SqlWrapper sql = SqlWrapper.Create(WrapperConnectionType.ShopNet, "sStore_InsertUpdate_v4")) { sql.AddParameter("StoreId", StoreId); sql.AddParameter("StoreName", StoreName); sql.AddParameter("Region", Region); sql.AddParameter("PostCode", PostCode); sql.AddParameter("Tel", Tel); sql.AddParameter("Email", Email); sql.AddParameter("RegionId", RegionId); sql.AddParameter("MapImage", MapImage); sql.AddParameter("ShopImage", ShopImage); sql.AddParameter("Visible", Visible ? 'Y' : 'N'); sql.AddParameter("TazEnabled", TasEnabled ? 'Y' : 'N'); sql.AddParameter("Latitude", Latitude); sql.AddParameter("Longitude", Longitude); sql.AddParameter("StoreOpeningDate", OpeningDate); sql.AddParameter("CustomerNo", CustomerNo); sql.AddParameter("ReserveAtStoreEnabled", RasEnabled); sql.AddParameter("OpeningHoursId", OpeningHours.Id); sql.AddParameter("AddressLine1", AddressLine1); sql.AddParameter("AddressLine2", AddressLine2); sql.AddParameter("City", City); sql.AddParameter("Dissortingct", Dissortingct); sql.AddParameter("County", County); sql.AddParameter("CountryCode", CountryCode); sql.AddParameter("GoogleCategories", GoogleCategories); sql.AddParameter("GooglePlacesEnabled", GooglePlacesEnabled); sql.AddParameter("ManagerName", ManagerName); sql.AddParameter("MapZoomLevel", MapZoomLevel); sql.AddParameter("IpAddress", IpAddress); sql.AddParameter("FlibbleEnabled", FlibbleEnabled); sql.AddParameter("RegionalManager", RegionalManagerId); sql.AddParameter("ShutlLogin", ShutlLogin); sql.AddParameter("ShutlPassword", ShutlPassword); sql.Execute(); } 

et permet d’éradiquer (mais pas d’oublier) ce type de batailles:

 System.IndexOutOfRangeException at System.Data.SqlClient.SqlDataReader.GetOrdinal(Ssortingng name) 

L’argument pour moi ne doit pas être plus compliqué que ça, j’ai quelques bonnes choses et quelque chose de terrible est enlevé. Nuff a dit, Suivant!

Personne ne prétend qu’un ORM est un remplacement à 100% pour tout ce qui est traditionnel. Ce ne sera pas un excellent outil pour écrire des rapports complexes, pour cela, utilisez des SP et des vues, et utilisez NHibernate pour les appeler en mode natif et les mapper automatiquement sur vos entités c #. Super, toujours toute la puissance de SQL et aucun code de cartographie de merde.

Soyez dans les ténèbres, stockeur de 0 et de 1, et venez ici la lumière de la bonne santé.

Un avantage est que votre couche de données est séparée de la couche d’object, donc lorsque vous avez plusieurs applications / projets dépendant de cette couche, vous la modifiez une fois dans l’ORM et toutes les applications / projets faisant référence à la couche d’object changer, comme sans lui, il faudrait modifier tous les projets.