XML semble être la langue de la journée, mais ce n'est pas le type de sécurité (sans outil externe pour détecter les problèmes) et vous finissez par faire une logique dans XML. Pourquoi ne pas simplement le faire dans la même langue que le reste du projet. Si c'est Java, vous pouvez simplement construire un pot de configuration et le mettre sur la classe de classe.
Je dois manquer quelque chose de profond.
8 Réponses :
Il n'y a rien de mal intrinsèquement avec la configuration en code, c'est juste que la tendance est d'utiliser XML pour fournir une certaine séparation.
Il y a une croyance généralisée que la configuration d'une manière ou d'une autre dans XML vous protège de devoir reconstruire après un changement. La réalité de mon expérience est que vous devez reconditionner et redéployer l'application pour fournir les fichiers XML modifiés (dans le cas du développement Web de toute façon), vous permettant ainsi de modifier facilement des fichiers "Configuration" Java. Yo pourrait déposer simplement les fichiers XML sur le serveur Web et rafraîchir, mais dans l'environnement que je travaille, l'audit aurait un ajustement si nous le faisions.
L'essentiel que l'utilisation de la configuration XML réalise à mon avis est de forcer les développeurs à réfléchir à l'injection de dépendance et à la séparation des préoccupations. Au printemps (entre autres), il fournit également un crochet pratique pour accrocher les proxy de votre AOP et ce type. Les deux peuvent être atteints dans la configuration Java, il est tout simplement moins évident où les lignes sont tirées et que la tendance peut être de réintroduire des dépendances directes et du code spaghetti.
Pour plus d'informations, il existe un Projet de ressort pour vous permettre de faire la configuration dans le code. < / p>
Le projet de configuration Java Spring Java (Javaconfig For bref) fournit une option de type-Java de type-Java pour la configuration du conteneur IOC à ressort. Tandis que XML est une approche de configuration largement utilisée, la polyvalence de ressort et la manipulation interne basée sur des métadonnées des définitions de haricots signifie des alternatives à la configuration XML sont faciles à appliquer.
Merci un groupe pour le lien du projet de printemps. Était complètement inconscient.
De rien, bien que ça vaut la peine de noter que ce n'est pas encore à 1.0
XML n'est pas destiné à avoir une logique, et il est loin d'être un langage de programmation.
XML est utilisé pour stocker des données de manière facile à comprendre et à modifier.
Vous dites, il est souvent utilisé pour stocker des définitions, pas la logique commerciale.
D'accord, que cela devrait être mais au printemps, il fait beaucoup plus que cela. Il est tout à fait possible de injecter des haricots et de sorte que la logique est dans le fichier XML.
L'inconvénient principal de la configuration DI en code est que vous forcez une recompilation afin de modifier votre configuration. En utilisant des fichiers externes, Reconfiguring devient un changement d'exécution. Les fichiers XML fournissent également une séparation supplémentaire entre votre code et votre configuration, que de nombreuses personnes valorisent hautement.
Cela peut faciliter la mise à jour, la maintenabilité, la mise à jour sur des systèmes distants, etc. Cependant, avec de nombreuses langues, vous pouvez utiliser une chargement dynamique du code en question et éviter certains des inconvénients, auquel cas les avantages diminuent.
Je trouve qu'un argument des flics. 99% du temps, si vous souhaitez modifier votre configuration DI, c'est un changement qui va assez profond pour que vous ayez besoin d'un recompilement de toute façon. Et tant que vous emballez vos classes de configuration séparément, il existe très peu de différence entre éditer un fichier XML et remplacer le test de configuration avec Config-Production. Les avantages d'autre part traitent d'une langue réellement lisible et que nous avons des charges de bateaux d'outils hautement évolués pour travailler.
(Ne veut pas dire de sortir tout comme "attaqué" comme ça sonnait, je t'ai voté parce que c'est pourquoi XML est utilisé pour cela. Je ne suis vraiment pas d'accord avec la vue)
Heh, je ne suis pas nécessairement d'accord avec ça non plus. Dans mon projet actuel, nous faisons beaucoup de DI CONFIGURATION (plus de configuration ORM) dans Code vs. dans XML, car cela a du sens pour nous. Cependant, il s'agit d'un argument fréquemment intégré et a sa place, c'est pourquoi je le mentionne. Personnellement, je préfère la configuration dans le code puisque vous obtenez une vérification du temps de compilation au lieu de devoir faire appel à des vérifications d'exécution de vos fichiers de configuration, mais c'est une préférence personnelle et non une réponse directement à la question.
Je ne pense pas que ce soit un flic sur tout. J'ai construit de nombreux systèmes de niveau d'entreprise et que des fichiers de configuration distincts permettent d'économiser de nombreuses maux de tête, en particulier lorsque vous devez mettre en œuvre dans différents environnements (c'est-à-dire de dev, qa, uat, prod). Si vous construisez une application pour vous-même ou une petite installation que peut-être que votre point pourrait être vrai. Mais pour les applications commerciales, la configuration de votre fichier XML est critique.
Quelle est la différence entre avoir des fichiers de configuration distincts et avoir des packages distincts di config? Il existe une différence entre la configuration de l'application et la configuration DI, la configuration de l'application doit être lisible par l'homme, la configuration DI n'a pas besoin d'être. La configuration de l'application peut être différente sur chaque machine, la configuration DI doit avoir des configurations spécifiques maximales 3 ou 4.
citer Fowler "Je pense souvent que les gens sont trop désireux de définir des fichiers de configuration. Souvent, un langage de programmation constitue souvent un mécanisme de configuration simple et puissant. Les langues modernes peuvent facilement compiler de petits assembleurs pouvant être utilisés pour assembler des plugins pour des systèmes plus volumineux. Si la compilation Est une douleur, puis il y a des langues de script qui peuvent bien fonctionner aussi. "
"On dit souvent que les fichiers de configuration ne doivent pas utiliser une langue de programmation car ils doivent être édités par des non-programmeurs. Mais à quelle fréquence est-ce le cas? Les gens s'attendent-ils vraiment vraiment à des non-programmeurs de modifier les niveaux d'isolation de la transaction d'un serveur complexe Application ultérieure? Les fichiers de configuration non linguistiques fonctionnent bien que dans la mesure où ils sont simples. S'ils deviennent complexes, il est temps de penser à utiliser un langage de programmation approprié. "
Martin Fowler a été assez bien couvert cette décision ici:
http://martinfowler.com/articles/injection.html
Éviter l'envie de plagier ... il suffit de lire la section "Code ou Fichiers de configuration".
Son mauvais parce que cela rend les tests plus difficiles.
Si vous écrivez le code et utilisez des méthodes telles que GetApplicationContext () pour obtenir les dépendances, vous jetez certains des avantages de l'injection de dépendance.
Lorsque vos objets et services n'ont pas besoin de savoir comment créer ou acquérir les ressources sur lesquelles elles dépendent, elles sont plus légèrement couplées à ces dépendances.
Couplage desserré signifie essais de l'unité plus facile. Il est difficile d'obtenir quelque chose dans un junit si vous avez besoin d'instancier toutes ses dépendances. Lorsqu'une classe omet des hypothèses sur ses dépendances, il est facile d'utiliser des objets simulés à la place de celles réelles aux fins des tests.
Également, si vous pouvez résister à l'envie d'utiliser gettaplicationContext () et d'autres di techniques basées sur le code, vous pouvez (parfois) faire appel à la mise en forme de ressort, ce qui signifie que signifie encore moins de configuration. Configuration Travaillez si dans le code ou en XML est fastidieux, non?
Si c'est ainsi que vous l'implémenteriez, vous ne faites pas d'injection de dépendance. Même si vous utilisez XML pour la configuration, vous devez toujours construire votre usine de haricots.
En effet, je discute de l'utilisation de GetApplicationContext ().
Vous avez mentionné le printemps dans un commentaire à votre question, cela suggère que vous pouvez être intéressé par le fait que le printemps 3 vous permet de C'est un peu un braft-bender, mais la définition de vos haricots et leurs intercendances, peuvent être effectuées en Java. Il conserve toujours une séparation propre entre la configuration et la logique, mais la ligne devient ce peu plus floue.
XML est principalement un format de données (nom). Le code est principalement un format de traitement (verbe). Du point de vue de la conception, il est logique de disposer de votre configuration en XML s'il s'agit principalement de noms (adresses, paramètres de valeur, etc.) et code si elle est principalement des verbes (drapeaux de traitement, configurations de gestionnaire, etc.).
Dans mon expérience, une communication étroite entre l'équipe de développement et l'équipe d'infrastructure peut être favorisée fréquemment. Plus vous publiez, plus vous saurez en réalité quelle est la variabilité entre vos environnements. Cela vous permet également de supprimer une configuration inutile.
Un corollaire à la loi de Conway s'applique ici - vos fichiers de configuration ressembleront à la variété des environnements que votre application est déployée sur (planifiée ou réelle).
Lorsque j'ai une équipe de déploiement d'applications internes, j'ai tendance à vous rendre à la configuration dans le code de toutes les préoccupations d'architecture (pools de connexion, etc.) et configuration dans les fichiers de toutes les configences environnementales (noms d'utilisateur, chaînes de connexion, adresses IP). S'il existe des préoccupations architecturales différentes selon les environnements différents, j'écoulerai ensuite ceux-ci dans une seule classe et apportez cette partie de classement des fichiers de configuration - E.g.
conteneur.config = fastinmemoryconfigurationfiguration conteneur.config = producteurConfiguration
Chacune d'entre elles utilisera une certaine configuration commune, mais remplacera / remplacera ces parties de l'architecture qui doivent être remplacées.
Ce n'est pas toujours approprié cependant. Il y a plusieurs choses qui affecteront votre choix:
1) Combien de temps il faut après avoir relâché une nouvelle goutte avant de se déployer avec succès dans chaque environnement de production et que vous recevez des commentaires sur cet environnement (temps de cycle) 2) la variabilité des environnements déployés 3) la précision des commentaires recueillis des environnements de production.
Ainsi, lorsque vous avez un client qui distribue votre application à leurs équipes de Dev pour le déploiement, vous devrez rendre votre application beaucoup plus configurable que si vous le poussez à vivre vous-même. Vous pourrait s'appuyer toujours sur la configuration dans le code, mais qui nécessite le public cible de comprendre votre code. Si vous utilisez une approche de configuration commune (E.G. Spring), vous facilitez les utilisateurs finaux d'adapter et de contourner les problèmes de contournement dans leur production.
Mais une rubrique est: la configuration est un substitut à la communication.
Qu'entendez-vous par "configuration"?
J'ai trouvé ce qui vous manque: la conformité des mots à la mode. ;-)
Au printemps, la configuration serait le câblage des haricots habituellement effectués via l'application de fichier XMLContext.xml
@LAURENCE: LOL, peut-être que c'est le royaume la question de la vie.