Quels types de projets de développement Web bénéficient de l'utilisation d'ORM?

Je commencerai par dire que j'ai fait 95% de mon travail de base de données en utilisant SQL. Récemment, j'ai fait des recherches sur divers ORM, tels que NHibernate et Doctrine.

Je peux voir les avantages de ne pas avoir besoin de connaître beaucoup de SQL et la portabilité de la base de données fournie par un ORM. Mais je peux aussi voir que la connaissance de SQL rendra le travail avec un ORM plus efficace et je ne peux penser qu'à une seule fois dans ma carrière que le plus grand changement d'une application serait le fournisseur de base de données.

Parce que je suis très à l'aise d'écrire du SQL et que je ne réalise apparemment pas les avantages souvent enseignés de l'utilisation d'un ORM, ma question aux gros utilisateurs d'ORM est la suivante:

Quels types de projets de développement Web profitent le plus de l'utilisation d'ORM?

(Presque) toutes les applications bénéficient d'ORM.

Tout d'abord, je ne suis pas d'accord avec les avantages que vous donnez pour ORM .

• L'utilisation d'ORM ne signifie pas nécessairement que vous n'avez pas besoin de connaître SQL. Une connaissance de SQL aidera à comprendre ce que fait réellement l'outil ORM, ce qui est particulièrement utile lors du débogage. De plus, SQL peut en fait être nécessaire pour développer des requêtes complexes qui dépassent les capacités de votre ORM choisi.
• Et comme vous le dites, la portabilité est rarement un problème dans la vie réelle.

Au lieu de cela, les vrais avantages de l'ORM sont:

• ORM fait gagner du temps au programmeur car il permet d'économiser des tonnes de logique CRUD en SQL
• de nombreux ORM incluent une logique de mise en cache complexe, etc. qui est difficile à écrire et à déboguer. En plus de gagner du temps, cela peut améliorer la fiabilité et la maintenabilité de votre application (ou au moins vous faire gagner du temps qu'il vous faudrait pour obtenir les mêmes résultats)
• les meilleurs ORM ont une communauté d'utilisateurs qui développent, entretiennent et soutiennent activement le produit. La communauté autour du SQL personnalisé est, au mieux, un peu moins concentrée sur les problèmes que nous devons résoudre.

Comme vous le commentez, l'un des inconvénients de l'ORM est la perte de performances. Cependant, cela peut généralement être compensé en dépensant plus de matériel.

En règle générale, le temps de programmation est plus cher que le matériel, donc ORM est généralement une bonne option au lieu de coder manuellement SQL.

ORM est le meilleur pour les applications avec beaucoup de logique de base de données CRUD assez simple. L'ORM est moins efficace pour :

• Applications nécessitant peu ou pas d'accès à la base de données.
• Applications largement dépendantes de requêtes complexes et très peu de logique CRUD simple
• Situations où les performances sont critiques, mais où il n'y a aucune possibilité de déployer un matériel plus rapide

D'après mon expérience, ces situations sont rares. D'où ma réponse.

Je suis également à l'aise pour écrire SQL. Je suis également beaucoup plus à l'aise de ne pas avoir à écrire de SQL du tout, ainsi que de ne pas me soucier de la connexion, de la déconnexion, de la mise en commun, etc. dans une base de données.

Alors .. je répondrai au négatif de votre question. Les seuls projets de développement Web qui ne bénéficient PAS d'un ORM sont ceux qui ne parlent pas du tout à une base de données. Je pense que c'est la minorité (le cas échéant).

Sur la base de mon expérience avec ASP.NET WebForms, je proposerais que les projets Web utilisant des cadres Web avec état bénéficient le plus de l'utilisation d'un ORM.

Avec un cadre dynamique, le balisage est généré automatiquement en arrière-plan, en fonction de la hiérarchie des contrôles serveur actifs. Il est tentant de charger ces contrôles et de conserver automatiquement leur état dans la base de données. C'est là que l'ORM aide.

Vous résumez en quelque sorte la fin du pipeline (sortie HTML) et cela invite naturellement à traiter le début (source de données) de la même manière afin de ne rester dans votre logique métier que dans le code d'application.

Non pas que je ne dis pas que c'est une bonne façon de faire les choses. C'est juste là où l'ORM s'intègre naturellement.

Dans les applications où vous avez un grand modèle d'objet très connecté, un ORM vous évite d'écrire les mêmes jointures encore et encore.

Un autre avantage est le chargement paresseux, où vous voulez qu'une API retourne un graphique d'objet où le client de l'API n'utilisera qu'un sous-ensemble de ce graphique.

Je crois que vous confondez un ORM avec un DBAL .

Le concept auquel vous faites référence est une couche d'abstraction de base de données (DBAL) qui vous permet d'écrire un "sql" portable qui ne dépend pas du système de base de données sous-jacent.

Un ORM d'autre part (qui est (presque?) Toujours construit au-dessus d'un DBAL):

Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. (Wikipédia)

En termes simples, un ORM vous permet de convertir les données d'une base de données plate en une représentation d'objet gonflée.

Les projets qui ne bénéficieraient pas de l'ORM seraient:

• ceux qui ne sont pas orientés objet;
• ceux qui n'ont pas besoin de conserver les données;
• ceux qui utilisent une base de données orientée objet, n'ont donc pas besoin de couche de mappage supplémentaire;
• ceux qui utilisent une solution NoSQL sans relation;