Discussion :

[Promeneur]

Le but est bien sûr de pouvoir changer de base de données sans avoir à changer les objets métiers ; pour cela, je voudrais une couche d’accès aux données, qui se charge par exemple de changer ou de mettre à jour un objet à partir de la base de données. En changeant de bases, je n’aurais que la couche d’accès aux données à reprogrammer.

Je ne parle pas ici vraiment de solution de mapping objet / base relationnelle, comme le fait NHibernate, par exemple. L’idée est que la couche d’accès pourrait soit faire appel à une couche de mapping comme NHibernate, soit des appels à un base purement objet, comme db4o ( www.db4o.com ).

Est-ce qu’il existe des frameworks de ce genre, en dot.net ? Si nous devons la programmer nous-mêmes, connaissez-vous des tutoriels, articles ou livres ?

Je me pose des questions comme si je fais un objet qui sert d’accès, par exemple AccesData, et que je luis passe en paramètre un objet à sauver, par exemple AccesData.Sauve(unClient), comment peut-il sauvegarder ce client, il faudrait qu’il ait accès à ses champs privés, non ?
Ou alors AccesData pourrait être dans une propriété des objets métiers, et ainsi avoir accès à leur données privées ?

Merci de vos lumières

Cordialement

Richard

[leMarseillais]

Je peut t'expliquer comment je procede si ca peut t'aider.
J'ai 5 couches dans mon appli:
- GUI
- Business Process (ou Logic)
- Business Objects
- Data Access Layer
- Database

Les Business Objects sont des objects crees independemment de la base de donnees, c'est la logique des applications. La couche suivante est celle qui appelle les SP (ou l'XML si tu changes ta base a XML, c'est la seule que tu modifieras). La regle est un BO pour un DAO. Par exemple, tu auras un BO Client et un DAOClient. le Client ne connait que son DAO associe dans le monde des DAO et le DAOClient ne connait que le Client dans le monde des BO. Ce qui te fais une isolation de couche car ce n'est que DAOClient qui doit connaitre quelle SP a appeller dans la couche inferieure.

Ca t'aide quelque part?

[leMarseillais]

Et d'accord principe 1: Definir les frontieres... Ne pas jouer a Tarzan a s'echanger les objects, si les frontieres sont bien definies, on a pas besoin d'echanger des instances entre services...

Donc j'en arrive a ma derniere question, qui est plutot la demande de "comment vous feriez ca vous???"

J'ai mon appli winform client. Normallement, tout user control a son propre BAL. Par contre la Business Logic se situe dans le service, qui peut lui etre heberge sur un serveur distant. Ce service aura lui aussi besoin des BALs, ce qui veut dire qu'on maintien 2 versions du BAL, pile ce que je veux eviter

Exemple concret:
J'ai un ecran CardPaymentUI qui a attache un CardProcessor (Logic) et un CardPayment (BAL) objet. Je cree dans l'ecran mon CardPayment lorsque l'utilisateur entre les donnees de la carte. Lorsque ce dernier clique sur "Proceder", on a truc style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CardProcessor.CardPayment = CardPaymentUI.CardPayment;
CardProcessor.Process();

Cette derniere ligne force le CardProcessor a appeller le TransactionService WCF Service qui lui doit comprendre ce qu'est un CardPayment afin de proceder l'operation. D'ou la reference de la DLL contenant CardPayment a 2 endroits different...

Suis-je clair?

[Promeneur]

Merci de ta réponse.

Je ne suis pas sûr de bien voir la différence entre les couches Business Process et Business Objects, dans un sens, pour moi, il s’agit bien de couche métier pour les deux. Mais c’est vrai qu’il y a des objets qui sont assez proches d’entités de données, à qui ont pourrait réserver l’appellation Business Objects, et d’autres qui sont plus des traitements, qui par exemple dépendent fortement de l’interaction avec l’utilisateur, et que l’on pourrait appeler Business Process. Est-ce que cela correspond à ton découpage, ou pas du tout ?

La couche suivante est celle qui appelle les SP (ou l'XML si tu changes ta base a XML, c'est la seule que tu modifieras). La regle est un BO pour un DAO. Par exemple, tu auras un BO Client et un DAOClient. le Client ne connait que son DAO associe dans le monde des DAO et le DAOClient ne connait que le Client dans le monde des BO. Ce qui te fais une isolation de couche car ce n'est que DAOClient qui doit connaitre quelle SP a appeller dans la couche inferieure.

Je ne sais pas ce que c’est qu’un SP, mais c’est bien ce que j’ai en tête pour la DAL : une association entre un BO et son objet d’accès aux données.

La question spécifique que je me suis posée, c’est comment le DAO sauve ou met à jour les champs privés du BO. Sur un autre forum, quelqu’un m’a donné une solution possible qui me semble assez simple, connue sur le nom de « Separate Interface Pattern ». Je pense la mettre en œuvre. Si je l’ai bien comprise, il s’agit d’exposer tous les champs à sauver, y compris privés, par une interface qu’implémente le BO. Le DAO peu ainsi accéder, à travers cette interface, aux données à sauver ou modifier.


Pour restreindre l’exposition des champs privés à la couche BO et à la DAL, cette interface est définie dans un assembly séparé dont seul la couche BO et a couche DAO ont les références, d’autre part les implémentations de l’interface sont explicites.

J’ai rapidement lu l’article dont tu donnes le lien. Cette approche semble intéressante, mais je n’ai pas le temps de l’étudier, en tenant compte de ma deadline. Donc j’en resterai à une vision OO plutôt qu’orientée services. Et je crains de ne pas comprendre ton dernier exemple. Peut-être parce que je ne sais pas ce qu’est un BAL et que je connais pas le TransactionService WCF Service .

[leMarseillais]

Ah!
Business Object (ou BO) est par exemple ta classe CardPayment. Elle ne contiendra que les methodes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Acquire() Update() Delete()

. C'est la representation pure de ton object, sans logique propre.
Business Process (ou BAL) est par exemple ta classe CardProcessor. Il contiendra des methodes telles que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ValidatePayment(), ProcessPayment()

... Mais il lui faut comme champ une instance de CardPayment afin de communiquer avec le service pour effectuer les traitements.

SP = Stored Procedure ou Procedure Stockee, c'est elle qui va executer la mise a jour ou le transfer de tes donnees.

Pour ta question specifique, les membres qui doivent etre mis a jour de ton BO sont dotes de proprety, qui sont donc accessibles a ta DAO. Je ne connais pas « Separate Interface Pattern » mais c'est une question de temps

[Promeneur]

Je ne suis pas sûr de voir l’intérêt de séparer les BO des BAL, dans l’exemple que tu donnes. En fait, pour notre application, en ce qui concerne la logique métier (et une bonne partie du côté « application distribuée », nous allons utiliser le framework CSLA, gratuit et expliqué dans un livre.

Dans ce framework, les BO héritent de classes métier de bases, qui ont des méthodes d’accès aux données, que l’on change dans les classes enfants, et que l’on peut utiliser pour communiquer avec une DAL.

Ce framework gère plusieurs choses, comme l’annulation multiple, un gestionnaire de règles métiers servant à la validation des objets, un gestionnaire de règles de sécurités… J’ai fait un message ici :
http://www.developpez.net/forums/sho...d.php?t=268772

Par ailleurs, sauver ou mettre à jour les objets en servant des propriétés me semble étrange. Par exemple, je peux avoir un champ privé dont divers aspects sont accessible, après clalculs par des Get, à travers des propriétés, mais le champ lui-même reste privé. De plus, parfois, en mettant à jour une propriété, donc par l'intermédiaire d'un Set, on déclenche des processus qui n'ont pas de sens dans le cas d'un chargement à partir de la base de données. Il me semble plus souple de pouvoir charger, sauver et modifier les champs plutôt que les propriétés.

[leMarseillais]

Je vois ce que tu veux dire pour les champs prives, en effet tout depend du concept que tu utilise. Mes proprietes servent juste a faire des Get Set simple, pour des champs calcules j'utilise dews methodes, c'est une differente facon de faire. Donc je n'ai pas de probleme pour mettre a jour l'object dans la BDD grace a ses proprietes...

Quand a CSLA, merci beaucoup ca m'interesse enormement, j'ai commande le bouquin!

[leMarseillais]

Dans l'exemple que je donne, effectivement, pas trop besoin de separer BO et BP, par contre, theoriquement, tu peut admetre que si tu as a changer le process de validation d'une carte , tu n'auras qu'a changer ton BP sans toucher ton BO, et si ces 2 couches sont separes alors ca te limite ton risque de test de probleme, d'ou l'idee de separation, moins de tests a effectuer diminution des potentiels impacts de problemes...

[Invité]

Bonjour, une question d'un simplpe quidam :

Et le framework 2.0 de .NET, il sert à quoi dans tout cela ?