4 votes

Quelle fonctionnalité intégrer dans les objets métier ?

Quelle fonctionnalité pensez-vous qu'il faut au minimum intégrer dans un objet métier persistant ?

Par exemple :

  • validation
  • un moyen de comparer à un autre objet du même type
  • la capacité d'annuler (la possibilité de revenir en arrière sur les changements)

2voto

hobodave Points 14566

La fonctionnalité dictée par le domaine et l'entreprise.

Lire Domain Driven Design.

1voto

Cat Man Do Points 11771

Un objet métier persistant devrait être composé des éléments suivants :

  • Données
  • Nouveau
  • Enregistrer
  • Supprimer
  • Sérialisation
  • Désérialisation

Souvent, vous abstraiterez la fonctionnalité pour les récupérer dans un référentiel qui prend en charge :

  • ObtenirParID
  • ObtenirTous
  • ObtenirParCritèresXYZ

Vous pouvez également encapsuler ce type de fonctionnalité dans des classes de collection (par exemple BusinessObjectTypeCollection), cependant il y a beaucoup de mouvement vers l'utilisation du Modèle de Référentiel dans la Conception Orientée Domaine pour fournir ce type d'accesseurs (par exemple InvoicingRepository.GetAllCustomers, InvoicingRepository.GetAllInvoices).

Vous pourriez mettre les règles métier dans les Méthodes Nouveau, Enregistrer, Mettre à jour, Supprimer... mais parfois vous pourriez avoir un moteur de règles métier externe auquel vous confiez les objets.

0voto

Yar Points 25421

Ceci n'est qu'une partie d'une réponse, mais je dirais que vous avez besoin d'un moyen pour accéder à tous les objets avec lesquels cet objet a une relation. Au début, vous pouvez essayer d'être intelligent et inclure uniquement la navigabilité à sens unique pour certaines relations, mais j'ai trouvé que c'est généralement plus ennuyeux que ça en vaut la peine.

Tous les frameworks persistants incluent également des finders, des moyens de faire des suppressions en cascade... des tris....

Une fois que vous commencez à modéliser, tous les objets métier devraient savoir comment se gérer eux-mêmes. Chaque fois que vous constatez qu'une autre classe fait référence TROP à votre objet métier, il est généralement temps d'incorporer ce comportement dans l'objet métier lui-même.

0voto

Jeffrey L Whitledge Points 27574

Des trois choses notées dans la question, je dirais que la validation est la seule qui soit vraiment nécessaire. Les autres dépendent de l'architecture globale de l'application.

De plus, les règles métier doivent être dans les objets métier.

Savoir si un objet doit gérer sa propre sérialisation est une question intéressante. J'ai eu beaucoup de succès dans le passé en faisant en sorte que chaque objet gère sa propre sérialisation, mais je peux aussi voir l'intérêt d'avoir un module de sérialisation qui charge et sauvegarde les objets métier de la même manière que l'interface graphique écrit et lit à partir des objets. Ensuite, votre validation protégera contre les erreurs dans la base de données ou les fichiers également.

Je ne peux penser à rien d'autre qui soit nécessaire en général.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X