Question

... quelle est la suite?

Après avoir défini quels acteurs font quelles actions, dans quelle direction allez-vous? Modélisez-vous la base de données ou préférez-vous commencer par les classes?

Je pensais que la meilleure approche consistait à commencer par un diagramme de modélisation de type classe, pour se concentrer sur les relations entre les objets. Cela s’est avéré être une erreur car j’ai trop approfondi les cours de détail et, même si le système "semblait fonctionner", lorsque je suis allé à la modélisation de la base de données, tout ne correspondait pas naturellement aux positions que j’avais choisies lors de la phase précédente. .

J'ai entendu parler de personnes qui disaient qu'il fallait placer la logique d'application dans une base de données et tirer parti de sa vitesse de récupération des données, par opposition à la création en mémoire d'objets volumineux interrogés et fournissant une abstraction de la base de données sous-jacente. J'ai toujours pensé que la base de données était là pour stocker mes données et fournir un moyen rapide d'y accéder. Mais peut-être que je me trompe, je veux dire, dois-je vraiment construire une base de données qui a dans la même logique que je mettrais sur un groupe de classes? La base de données ne manque-t-elle pas d'outils pour y parvenir?

Je pense que je ne parviens pas à identifier le bon point de départ. Si je choisis de commencer par la base de données, j'ai du mal à ne pas y penser simplement comme un "lieu de stockage pour mes données, faisons de la logique d'application". à un niveau supérieur " Si je commence par les classes, la base de données finit par ressembler à une représentation non naturelle des classes, je ressens la sensation de manquer quelque chose d’important, comme ne pas assigner le bon but au bon outil.

Comment gérez-vous cela? Selon votre expérience, quelle sorte d’approche s’est révélée aboutir à une implémentation naturelle et propre? Décidez-vous de commencer par modéliser la base de données ou les classes?

Merci d'avance

Était-ce utile?

La solution

J'ai réussi à utiliser l’ Analyse de robustesse .

  

Cet article porte sur la robustesse   l'analyse, qui consiste à analyser les   texte narratif des cas d'utilisation et   identifier un ensemble de première hypothèse de   objets qui participeront à chaque   cas d'utilisation, puis en les classant   objets en trois types:

     
      
  1. Objets limites que les acteurs utilisent pour communiquer avec le système.
  2.   
  3. Les objets Entity, qui sont généralement des objets du modèle de domaine   (sujet de "Driving Design: The   Domaine du problème, " Janvier 2001).
  4.   
  5. Les objets de contrôle (que nous appelons généralement les contrôleurs car ils   souvent ne sont pas de vrais objets), qui   servir de "colle" entre les limites   objets et objets d'entité. Figure 1   montre les icônes visuelles pour ces trois   types d'objets.
  6.   

Les objets d'entité sont ceux qui se retrouvent (généralement) dans la base de données /

À propos du mappage entre les classes et la base de données, je recommanderais Article de S.Lott sur "Le problème ORM" (il participe également à StackOverflow

Autres conseils

Si vous utilisez le développement dirigé par les tests, écrivez d'abord vos tests unitaires. Vos cours seront définis au fur et à mesure.

Vous pouvez choisir de développer votre logique métier sans base de données (objets fictifs ou stub) ou de développer votre base de données au fur et à mesure de vos tests.

N'oubliez pas que votre base de données et votre modèle de domaine ne doivent pas être associés l'un à l'autre.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top