Développement de l'application N-Tier. Dans quelle direction?

Question

En supposant que vous implémentez une user story qui nécessite des modifications dans toutes les couches de l'interface utilisateur (ou de la façade de service) à la base de données.

Dans quelle direction vous déplacez-vous?

• De l'interface utilisateur à la couche métier, du référentiel à la base de données?
• De la base de données au référentiel, de la couche de gestion à l'interface utilisateur?
• Cela dépend. (Sur quoi?)

Answer 1

La meilleure réponse que j'ai vue à ce type de question a été fournie par les gars de l'objet atomique et leur Présentateur d'abord . En gros, il s’agit d’une implémentation du modèle MVP dans lequel (comme son nom l’indique), vous commencez à travailler à partir de Presenter.

Ceci vous fournit un objet très léger (puisque le présentateur est généralement là pour rassembler les données du modèle dans la vue et les événements de la vue dans le modèle) qui peuvent directement modéliser votre ensemble d'actions utilisateur. Lorsque vous travaillez sur le présentateur, la vue et le modèle sont généralement définis en tant qu'interfaces et sont simulés. Votre objectif initial est donc de définir la manière dont l'utilisateur interagit avec vos objets.

J'aime généralement travailler de cette façon, même si je ne fais pas un modèle MVP strict. Je trouve que le fait de mettre l'accent sur l'interaction utilisateur m'aide à créer des objets métier plus faciles à utiliser. Nous utilisons également Fitnesse pour les tests d’intégration, et j’ai trouvé qu’écrire les appareils pour Fitnesse tout en construisant mon Les objets métier permettent de centrer l'attention sur le point de vue de l'utilisateur sur l'histoire.

Je dois dire cependant que vous vous retrouvez avec un cycle TDD assez intéressant lorsque vous commencez par un test de Fitnesse échoué, puis que vous créez un test unitaire défaillant pour cette fonctionnalité et que vous remontez la pile. Dans certains cas, j'écris également des tests unitaires de base de données. Il existe donc une autre couche de tests à écrire, qui a échoué et réussi, avant la réussite des tests de Fitnesse.

Answer 2

Si un changement est probable, commencez à l'avant. Vous pouvez obtenir un retour immédiat des actionnaires. Qui sait? Peut-être qu'ils ne savent pas réellement ce qu'ils veulent. Regardez-les utiliser l'interface (interface utilisateur, service ou autre). Leurs actions pourraient vous inciter à voir le problème sous un jour nouveau. Si vous pouvez intercepter les modifications avant de coder les objets de domaine et la base de données, vous gagnez un temps précieux.

Si les exigences sont rigides, ce n'est pas aussi important. Commencez par la couche qui sera probablement la plus difficile - abordez les risques rapidement. En fin de compte, c’est l’un de ceux qui «constituent davantage un art que la science». problèmes. C’est probablement une interaction délicate entre la conception des couches qui crée la meilleure solution.

A bientôt.

Answer 3

Je le ferais de bas en haut, car vous obtiendrez des résultats rapides (vous pouvez écrire des tests unitaires sans interface utilisateur, mais vous ne pouvez pas tester l'interface utilisateur tant que le modèle n'est pas terminé).

Il existe cependant d'autres opinions.

Answer 4

Je commencerais à modéliser le domaine problématique. Créez des classes pertinentes représentant les entités du système. Une fois que je me sentais à l'aise avec cela, j'essayais de trouver un mappage réalisable pour conserver les entités dans la base de données. Si vous mettez trop de travail dans l'interface utilisateur avant de disposer d'un modèle de domaine, vous risquez fortement de devoir retravailler l'interface utilisateur par la suite.

En y pensant, vous aurez probablement besoin de mettre à jour de toute façon toutes les couches ... =)