Passer aux ORM

Question

Je joue avec l'idée d'intégrer progressivement un ORM dans une application que je prends en charge.L'application n'est pas très structurée et ne contient pas de tests unitaires.Tout changement sera donc risqué.Je crains évidemment d'avoir une raison suffisamment bonne pour changer.L’idée est qu’il y aura moins de code passe-partout pour l’accès aux données et donc une plus grande productivité.

Est-ce que cela sonne vrai avec vos expériences ?
Est-il possible, voire une bonne idée, de le mettre en place progressivement ?
Quels sont les inconvénients d’un ORM ?

Answer 1

Je recommanderais fortement de vous procurer un exemplaire du livre de Michael Feather Travailler efficacement avec le code existant (par "Legacy Code", Feathers désigne tout système qui n'est pas suffisamment couvert par les tests unitaires).Il regorge de bonnes idées qui devraient vous aider dans votre refactorisation et la mise en place progressive des bonnes pratiques.

Bien sûr, vous pouvez introduire progressivement un ORM, en l'utilisant initialement pour accéder à un sous-ensemble de votre modèle de domaine.Et oui, j'ai constaté que l'utilisation d'un ORM accélère le temps de développement - c'est l'un des principaux avantages et je ne manquerai certainement pas l'époque où je construisais laborieusement à la main des couches d'accès aux données.

Inconvénients de l'ORM : par expérience, il y a inévitablement une certaine courbe d'apprentissage pour maîtriser les concepts, la configuration et les particularités de la solution ORM choisie.

Modifier:nom de l'auteur corrigé

Answer 2

Le livre "Robert C Martin", qui a en réalité été écrit par Michael Feathers ("Uncle Bob" est, semble-t-il, une marque de nos jours !) est un incontournable.

Il est presque impossible - sans parler du temps incroyablement long - d'intégrer des tests unitaires dans une application qui n'est pas développée avec eux.Le code ne sera tout simplement pas acceptable.

Mais ce n'est pas un problème.Le refactoring consiste à changer la conception sans changer la fonction (j'espère que je n'ai pas trop corrompu le sens ici) afin que vous puissiez travailler de manière beaucoup plus large.

Commencez avec de gros morceaux.Configurez une exécution reproductible et capturez ce qui se passe comme résultat attendu pour les exécutions ultérieures.Vous avez maintenant votre application, ou une partie de celle-ci, en cours de test.Ce n'est pas un test très bon ou complet, bien sûr, mais c'est un début et les choses ne peuvent que s'améliorer à partir de là.

Vous pouvez maintenant commencer à refactoriser.Vous souhaitez commencer à extraire votre code d'accès aux données afin qu'il puisse être remplacé par la fonctionnalité ORM sans trop déranger.Testez souvent :avec les applications existantes, vous serez surpris de ce qui se casse ;la cohésion et le couplage sont rarement ce qu’ils pourraient être.

J'envisagerais également de regarder celui de Martin Fowler Refactorisation, qui constitue, de toute évidence, le travail définitif sur le processus.

Answer 3

Je travaille sur une grande application ASP.net sur laquelle nous avons récemment commencé à utiliser NHibernate.Nous avons plutôt déplacé un grand nombre d'objets de domaine que nous avions persistés manuellement vers Sql Server vers NHibernate.Cela a beaucoup simplifié les choses et a rendu beaucoup plus facile la modification des choses au fil du temps.Nous sommes heureux d'avoir apporté les modifications et d'utiliser NHibernate lorsque cela est approprié pour une grande partie de nos nouveaux travaux.

Answer 4

J'ai entendu dire que TypeMock est souvent utilisé pour refactoriser le code existant.

Answer 5

Je pense sérieusement que l'introduction d'ORM dans une application existante pose problème (et pourrait représenter le même nombre de problèmes qu'une réécriture complète).

En dehors de cela, ORM est une excellente solution et doit absolument être pris en compte.

Answer 6

La règle pour le refactoring est la suivante.Faites des tests unitaires.

Alors peut-être devriez-vous d'abord effectuer des tests unitaires au moins pour les éléments principaux/essentiels.

L'ORM doit être conçu pour diminuer le code passe-partout.Le temps/problème vs.Le ROI d'une entreprise, c'est à vous de l'estimer :)

Answer 7

À moins que votre code ne soit déjà architecturé pour permettre le « échange à chaud » du backend de votre couche de modèle, le modifier de quelque manière que ce soit sera toujours extrêmement risqué.

Essayer de créer un filet de sécurité de tests unitaires sur un code mal architecturé ne garantira pas le succès, mais vous permettra seulement de vous sentir plus en sécurité lors de sa modification.

Ainsi, à moins que vous n’ayez une solide analyse de rentabilisation pour assumer les risques encourus, il est probablement préférable de laisser cela de côté.