DAO & amp; BO (couche d'accès aux données) - architecture
Je suis un peu confus au sujet d'un exemple trouvé sur le web - printemps & hibernate (point 4. Model & BO & DAO
). Il y a le Modèle, les DAO et les BO classes (+ DAO et BO interfaces). Ce que je n'ai pas clairement comprendre, c'est pourquoi les DAO et les BO sont séparés en différentes classes si elles ne partagent pas exactement les mêmes fonctionnalités (seule différence est que le BO a un DAO setter).
L'auteur explique que le motif:
est utile pour identifier la couche clairement pour éviter de gâcher de la structure du projet
mais il semble conçu pour moi (au moins dans ce cas). Je sais que cet exemple est très simple, mais que cette classe de séparation pourrait être utile? Quelqu'un pourrait-il me donner un exemple?
source d'informationauteur ducin
Vous devez vous connecter pour publier un commentaire.
Ce qu'ils appellent un BO semble être un service de l'entreprise. Un DAO travail est de contenir la persistance de code: insertion, mise à jour, l'interrogation de la base de données.
Les services de délimiter les transactions, contiennent la logique métier, et utilisent généralement un ou plusieurs DAOs pour mettre en œuvre cette logique. Pour certains cas d'utilisation, le service des délégués à la DAO. Pour d'autres, il appelle plusieurs méthodes d'un ou de plusieurs DAOs.
L'exemple classique est un service de transfert d'argent: