Réflexions sur mon approche MVC (données + domaine + logique métier). Newb

Question

J'écris une application de facturation médicale et j'utilise MVC (Spring) pour la première fois, donc j'ai du mal à obtenir une approche qui me semble juste. Des pensées/commentaires seraient appréciés.

Mon "domaine" classes

• Docteur
• patient
• réclamation
• BusinessLogic

Mes classes contrôleur

• L istPatients
• EditPatients
• FindPatients
• SubmitClaim

Mes classes dépôt

• IPatientDao
• IDoctorDao
• IClaimDao

Mon application est très "lourde". Par exemple, les médecins ne peuvent pas supprimer les patients d'autres médecins. Les patients ne peuvent pas être supprimés s'ils ont été facturés pour quelque chose.

Je pense que ces règles ne devraient pas être capturées dans les contrôleurs, ce qui semble sale, surtout si une règle devait être utilisée dans plusieurs contrôleurs. De même, je pense que mes objets DAO sont pour lire & en écriture seulement, pas en validation. En conséquence, j'ai fait un objet BusinessLogic qui a le cerveau. Je peux donc appeler quelque chose comme:

businessLogic.deletePatient (patient, médecin); // renvoie true/false et définit un message

Ceci permet de vérifier si le médecin connecté a le droit de supprimer un patient spécifique.

Pour moi, cela semble le meilleur moyen de garder tout rangé.

Bon ou mauvais? Quoi de mieux?

Answer 1

Je me sens pour une architecture MVC ... ici devrait être le flux de COUCHES ....

a) class..like d'action que nous avons en Struts ... tous les paramètres de la page Web doit être traité dans cette classe ... toutes les validations doivent être traitées par des validateurs de formulaires ...

b) de cette classe d'action, appelez votre classe affaires qui fait toute la logique sans activité pour une action donnée .... dites facturation patients ... cela va obtenir les médecins associés et dire donner une commission aux médecins pour cela ...

c) couches DTO ... setter getter pour toutes les classes dans votre application ... peut être utilisé par toutes les couches ... patients, factures, médecins, etc peuvent être quelques exemples ...

d) DAO layer..the oe qui interagit avec la base de données ... il peut interagir en utilisant hibernate, JDBC etc ... a toutes les requêtes écrites en eux ... faire toutes les choses de mise en cache etc ...

Ainsi, la couches sont

action appelle la couche d'affaires appelle la couche DAO ..DTO peut être utilisé par toutes les couches et peut être également envoyer comme objet de requête Retour à la page JSP pour displyaing données ...

Answer 2

Le modèle de domaine me semble désespérément naïf, car il ne comprend rien pour traiter avec les compagnies d'assurance ou une interface pour un système de comptes créditeurs/recevables. Mais peut-être en êtes-vous à un stade précoce et essayez simplement un modèle simple avant de le construire. Je ne pense pas que je réifierais un objet BusinessLogic. Trop générique. Si vous utilisez Spring, je me demande si vous pourriez mieux tirer parti de la programmation orientée aspect pour l'application de vos règles.

Je voudrais savoir si oui ou non Spring support pour JSR-94 pourrait vous aider. Peut-être que vous pourriez intégrer un comportement complexe dans les objets en utilisant des moteurs de règles.

Le meilleur conseil est de lire le chapitre et le verset du langage superposant Printemps recommandé:

1. action Struts < Spring contrôleur;
2. business class ~ Service de ressort
3. Nix les DTO - pas typiquement utilisés au printemps. Ce sont les anti-patterns restants d'EJB 1.0.
4. DAO/repository est recommandé idiome de printemps. JPA garde les choses génériques.