Le cadre GRAVES a beaucoup de constructions / fonctionnalités permettant d'adhérer au principe sec ("Ne pas répéter toi-même") dans un projet. C'est-à-dire: dans un projet spécifique, vous êtes rarement tenu de répéter des blocs identiques de paramètres ou de code. Jusqu'à présent, si bon.
Cependant, plus j'ai travaillé avec des greils, plus j'ai observé que je répète le code non dans le même projet, mais entre les projets. C'est-à-dire que le projet A a des contrôleurs, SPG: s et des images qui chevauchent avec le projet B. Il s'agit d'un cauchemar de maintenance, car les correctifs de bogues dans le projet A doivent également être fixés dans le projet B, etc.
J'aimerais prendre sécher au niveau supérieur en ne faisant pas double emploi du code entre mes projets.
Ma question: Comment vous attaquez-vous à ce problème (violé "Inter-projets secs") dans vos propres projets de greils internes?
S'il vous plaît soyez très spécifique / concret. Si possible, essayez d'inclure des exemples de code spécifiques sur la manière dont vous le résolvez dans la pratique.
3 Réponses :
Écrire un plugin personnalisé est le meilleur moyen. Vous n'avez pas besoin de le relâcher au référentiel public, car vous pouvez utiliser un référentiel privé quelque part dans votre propre réseau.
Je n'ai pas encore eu assez de code dupliqué pour sortir un plugin (la plupart du code répété dans mes projets semblent être couverts par les différents plug-ins), mais un plugin peut être aussi simple que quelques classes de domaine communes ou des services.
Je suis d'accord avec Lee, en utilisant des plugins communs / partagés est probablement le meilleur moyen d'y aller. Au même endroit que j'ai travaillé, nous avons eu plusieurs plug-ins internes pour cette raison même.
Le modèle le plus courant est de placer vos objets de domaine communs dans leur propre plugin. Cela fonctionne vraiment bien pour les classes de domaine ou les services. Nous n'avons pas fini par refactoring les contrôleurs, les vues et les ressources statiques dans un plugin, mais le même principe devrait s'appliquer.
histoire longue courte: réutilisation des grails artifacts = Utilisez un plugin.
Pour ajouter aux points de Lee et Colin, qui sont tous deux valides, je pense que penser en termes de plugins multiples peut donner d'autres avantages.
Par exemple, vous pouvez diviser votre fonction de fonctionnalité de votre application en plusieurs morceaux et avoir des personnes différentes de travailler sur eux. Ou il peut donner des résultats lors du déploiement, si, par exemple, vous devez avoir deux couches d'accès à une application - Niveau utilisateur et Admin - Si votre modèle de domaine est dans un plugin séparé, comme le suggère Colin, vous pouvez facilement construire deux applications. et les déployer séparément.
Pour mon application, j'ai plusieurs plug-ins spécifiques à mon projet - Plugin de classes de domaine, un groupe de code pour importer des données (que je peux courir facilement sur mon site), d'autres plug-ins pour la graphique et la personnalisation des échafaudages. . Cela prend un peu plus de pensée, mais je m'attends à ce que cet affacturage produira des dividendes à l'avenir, car nous apportons plus de personnes à l'équipe.