[Architecture][WCF] Application client/serveur : développement en couches

Hello,

Habituellement, nous développons plutôt des applications "client lourd" en utilisant l'architecture suivante :
Pièce jointe 192771
GUI : Graphical User Interface (contient les winforms)
BLL : Business Logic Layer (contient les classes avec les règles métier)
DAL : Data Access Layer (contient les classes qui accèdent à la DB)
DTO : Data Transfert Object (contient les objets métier)

Pour une application client/serveur (utilisant WCF pour la communication), je m'interroge sur la place de certaines choses...

Evidemment, la couche GUI est le client en lui-même.
La couche DAL sera bien sûr consommée par le serveur.
La couche DTO, j'imagine que ce sont en fait les classes portant l'attribut DataContract de WCF.
Ma plus grosse interrogation concerne la couche BLL. Je suis tenté de dire qu'une partie est en fait le ServiceContract de WCF. Mais ce ne doit pas être tout.

Faut-il une couche BLL pour le client et une autre pour le serveur ? Car chacun peuvent avoir des besoins de validations différents/complémentaires.

N'ayant jamais eu de cours d'architecture logiciel, je me tourne vers vous pour m'orienter dans la bonne direction.

Hello,

Je peux te faire part de comment c'est part chez moi pour l'instant.

On a exactement la même configuration que toi, sauf qu'elle est en 5-tiers (WCF donc).
Et ça se traduit en fait part :

DAL - BLL- WCF côté serveur
GUI - BP côté client

Sachant que la couche WCF (Service) est générée automatiquement à partir des procédures publiques de la couche BLL et contient les services
et la couche BP (Coordination) est générée elle aussi automatiquement pour contacter ces service (à partir de la BLL ou du WCF, je sais pas).

Ce qui fait qu'on ne développe (à la main) que les même trois couches que toi, les deux autres, étant des couches "virtuelles" générées automatiquement, on a rien à faire.

Du coup, côté GUI, dans le code, il n'y a que du léger, dès qu'il y a du traitement, on l’envoi au serveur.

Je sais pas si ça aide.

Ca aide mais ce n'est pas encore tout à fait clair.

Pour être précis, voici ma démarche jusqu'ici.

J'ai créé une solution histoire de testé le wcf et j'y ai mis ceci : (chaque point est un projet dans la solution)

• Client : application winforms qui a une dépendance vers Contracts
• Contracts : bibliothèque de classes qui contient les contrats WCF, cad les opérations et les types de données qui peuvent être effectuées/échangées via le service WCF
• Server : le service wcf en lui-même qui a donc forcément une dépendance vers Contracts aussi
• ServerHost : application console qui héberge le service WCF (à terme, le service WCF sera p-e hébergé par un service windows mais je ne pense pas que ce soit le plus important pour le moment) et qui a donc une dépendance verse Server (et donc vers Contracts).

Une fois que j'ai eu fait joujou avec ça et que je suis parvenu à faire communiquer le client et le server (simplement dire bonjour et avoir une réponse), j'ai voulu créer "une vraie" architecture.

Du coup, machinalement, j'ai jouté un projet DTO (bibliothèque de classes) et un projet DAL (bibliothèque de classe). Puis quand j'ai réfléchi à ce que j'allais mettre, les questions sont apparues...

Au niveau de la DAL, c'est encore relativement clair. Y a pas grand chose qui change par rapport à d'habitude. Ce projet va contenir ce qu'il faut pour persister les données.

*révélation*

En fait, en détaillant, je me rend compte que ce dont j'ai besoin, c'est un projet* complet pour le client et un projet* complet pour le serveur. En fait, on a besoin pour ce cas-ci d'une application client-serveur car les utilisateurs "vont devoir aller chercher" des infos sur des machines auxquelles ils n'ont pas accès normalement. Du coup, plutôt de donner des autorisations firewall à tout le monde, on fait une application client-serveur et il n'y a plus que le serveur qui a besoin de ces autorisations spécifiques. Par contre, une fois ces infos récupérées, l'utilisateur va faire certains traitements et persister le résultat de ce traitement sur le même serveur de DB qu'on utilise tout le temps (et auquel ils ont déjà accès).
* : projet au sens informatique, pas projet au sens de VS

Donc la récupération des infos sensibles se fera via l'application serveur et la persistances des données après traitements se fera via l'application client sur le SGDB habituel. Du coup, vu que j'aurai deux projets d'application totalement séparés, les questions de savoir ce qui va où, ce qui est en commun ou pas ne se posent plus. Il y a aura probablement des bouts de codes en commun notamment au niveau des objets métiers mais ceux-ci seront dans le contrats WCF si mes idées sont claires.

J'sais pas trop si je me fais bien comprendre ^^.

Bref, je vais bosser un peu et je reviens vers pour confirmer que ma révélation est bonne ou pas :mouarf:

Hello,

Juste pour confirmer que ma vision des choses semble être correcte vu que tout s'emboite bien pour le moment.

Dernier détail qui me chiffonne.

Quelle couche du client doit implémenter l'interface callback du service WCF ?

Pour tester si le service était fonctionnel, j'avais bêtement taper le code directement dans le GUI sur la winform ce qui donnait ceci :

Code:

---

1 2 3

Public Sub ReceiptTicketData(ticket As Ticket) Implements IInvoiceServiceCallback.ReceiptTicketData DataGridView1.DataSource = ticket.Articles End Sub

---

J'avais effectivement les infos affichés dans le datagridview donc j'étais content.

Maintenant que je passe aux choses sérieuses, il faut structurer le tout correctement. Je m'étais dit que j'allais mettre ça dans la couche métier mais vu que cette dernière est référencée par la GUI et pas l'inverse, la couche métier ne peut pas aller mettre d'elle-même les infos dans le contrôle qui servira pour l'affichage.

En résumé, elle ne peut pas triggerer l'affichage des infos. Et c'est bien ce qui me pose problème...

*TILT*

Et si la classe métier implémente l'interface INotifyPropertyChanged et que j'implémente l'évènement qui va bien dans la couche graphique, ça doit pouvoir passer non ? J'ai très peu utiliser ce truc là. Un retour quelqu'un ??

Un p'tit dernier pour signifier que tout fonctionne très bien avec l'interface INotifyPropertyChanged.