Meilleure approche du modèle, de la vue et du contrôleur séparé

Je pense qu'il est également important de déterminer comment vous souhaitez utiliser le fait que vous avez divisé des modules séparés dans votre base de code. C'EST À DIRE. Quel type d'utilité autre que la qualité du code de base cherchez-vous à exploiter en fonction de votre schéma d'emballage.

La plupart des applications que je travaille sur la structure d'emballage suivante: * .domain, * .service.subservice, * .dao, * .web.Controls. Cela fonctionne bien pour suivre les dépendances cycliques dans la base de code et / ou les dépendances qui circulent dans le mauvais sens (contrôleur frappant le DAO sans l'indirection d'un service). Il fournit également une structure d'emballage très simple qui est utile et non bourdonnée.

Cependant, cela se décompose lorsque vous examinez des évaluations automatisées de dépendance. J'utilise actuellement dépendancesFinder avec un peu de code personnalisé pour comparer deux fichiers JAR avant qa. DépendencyFinder tire toutes les méthodes modifiées et leurs dépendances de premier niveau associées. Le code personnalisé doit lancer pour cartographier les méthodes / classes modifiées vers des fonctions commerciales et accrocher un fichier graphique graphviz pour rendu un jeu de modifications basé sur la fonction d'entreprise, un graphique de dépendance pour QA. Nous essayons actuellement d'utiliser les résultats de l'outil de planification des tests de régression intelligente, en particulier pour les défauts de production qui se déplacent à la production sans test de régression de plusieurs semaines.

La structure de répertoire que vous proposez fera beaucoup plus facilement le second cas. Cependant, j'ai également constaté que la majeure partie de mon équipe de développement ne s'en soucie pas vraiment de dépendances du tout, l'utilité du vérificateur de dépendance automatique peut varier :)

Voici un exemple en utilisant une architecture architecture en couches avec trois couches ( application, domaine, UI ):

dans le modèle-View-contrôleur (MVC) Le modèle serait dans une couche inférieure, telle que com.company.myapp.domain . Toutes les autres couches peuvent accéder au modèle. Ensuite, la vue et le contrôleur seraient dans com.company.myapp.ui . Cela signifie que la classe contrôleur est toujours dans la même couche que celle . Ne confondez pas le contrôleur MVC avec d'autres classes de contrôleur qui fournissent la logique d'application et résident dans la couche d'application. Par exemple, un SalesController dans com.company.myapp.application , qui fournit des opérations système pour gérer les ventes.

Vous pouvez maintenant imaginer que le SalesController modifie certaines données de votre modèle (mise à jour d'une vente) et le modèle informe ensuite le contrôleur MVC qui met à jour la vue.

Remarque: Tous les modèles sont dans le calque domaine . Toutes les vues et contrôleurs MVC sont dans la couche ui . Les contrôleurs logiques commerciaux se trouvent dans le calque application . Vous pouvez bien sûr subdiviser ces trois couches plus loin si vous avez de nombreuses classes avec des préoccupations différentes.

J'espère que cela vous aidera.