Discussion :

[Ilaoet]

Bonjour,

Dans le cadre d'un développement je suis confronté à un problème.

Le but est qu'une application cliente soit capable de lister et d'instancier des "composants"

définit dans différentes DLL.

Les "composants" envoi un UI WPF au client qui l'affiche sans connaitre le type concret du

composant, mais seulement l'interface qu'implémente tous les "composants".

La possibilité d'ajouter un "composant" sans recompilé l'application cliente est vitale pour

ma solution.

Jusque là rien de bien compliqué, c'est la que je vous précise que le client et les composants

communiquent par WCF.

Deux problèmes se présente à moi:

• Les interfaces ne peuvent pas être décorés par l’attribut [DataMember]
• Les UI ne sont pas serializable

Une des solutions que j'ai penser est d'envoyer la DLL via le WCF et que le client le gère

comme une DLL locale. Mais je pourrais rencontrer des problèmes de sécurité.

Avez-vous une idée sur une autre architecture pour cette solution ? Ou avez-vous des pistes

que vous me conseillez d'explorer ?

En vous remerciant

[DotNetMatt]

Tu peux envoyer la DLL directement, puis la charger dynamiquement. Ca reste à mon avis le meilleur moyen de procéder dans ton cas. Par contre, à toi de bien encadrer l'envoi des DLL et de vérifier qu'elle n'ait pas été interceptée et modifiée durant le trajet...

Il y aurait d'autres solutions envisageables à base de reflection, mais ce n'est pas forcément une bonne idée en terme de performance.

D'une manière plus générale, je pense que c'est une mauvaise idée de procéder ainsi. Tu as probablement bâclé ton architecture, ce qui t'amène à devoir réaliser ce genre de choses...

La modularité, c'est bien mais il y a des limites dont il faut tenir compte

[Ilaoet]

D'une manière plus générale, je pense que c'est une mauvaise idée de procéder ainsi. Tu as probablement bâclé ton architecture, ce qui t'amène à devoir réaliser ce genre de choses...

La modularité, c'est bien mais il y a des limites dont il faut tenir compte

Étant donner que le projet n'est pas encore parti et que je suis plus en phase d'analyse, l'architecture n'est pas encore fixée.... Donc pas (encore ?) baclée...

Tout ça pour dire que si tu as un petit conseil plus concret, qui pourrait m'aiguiller à améliorer mon architecture, je suis grandement preneur.

Dans tout les cas, merci de ta réponse.

[DotNetMatt]

sûrement une déformation professionnelle, à force de voir des choses un peu bizarres sur le forum

Donc si tu es toujours en cours d'études sur le sujet, le principal conseil que je pourrais te donner, c'est de rester le plus proche possible des design patterns existants. La modularité d'une application, c'est très bien. Mais à condition de rester dans des standards d'implémentation, sous peine de se retrouver avec une application difficilement maintenable et reprenable par quelqu'un d'autre ou par une autre équipe. Il faut penser à ces choses-là dès le début du projet, car on a vite fait d'exploser les budgets maintenance, puisqu'une fois qu'on commence à en faire, il n'est plus possible de revenir en arrière.

Concernant ton cas plus précisément, je pense que c'est une erreur d'envisager la modularité de cette façon. En effet, l'UI est censée être clairement définie, avec la possibilité d'avoir plusieurs vues, le routage vers la bonne étant fait par le Controller/Presenter/ViewModel.

Quelles sont les technos utilisées sur ton projet ? Est-ce que tu vas utiliser un pattern tel que MVC ou MVP ou MVVM (ou autre) ?

[Ilaoet]

Les composants sont des tâches et le client sert à configurer et lancer l’exécution de ces tâches.
Dans mon architecture je dois tenir en compte que la liste des tâches peut évoluée. Donc je suis parti sur un pattern Plug-In afin d'éviter de devoir recompiler une solution à chaque composant ajouté.

Le UI du composant représente la vue de configuration de ce composant, donc il est propre à chaque composant et impossible à fixer maintenant. Donc oui le UI est clairement défini par composant, mais pas globalement pour l'application.

Une de mes premières idées était de laisser le client construire le UI en fonction des paramètres (propriété) à configurer sur le composant, mais je n'aime pas cette solution qui ajoute une dépendance visuel entre les composants. (Tout les int seront représenté de la même manière, etc...) Et qui bloquerait les composants qui devrait sortir de l'ordinaire (j'ai pas d'exemple tout fais la ).

Et l'idée de laisser le composant seul maitre de sa tache et sa configuration me plaisait bien.

Si je ne suis pas sur du WCF cette façon de faire fonctionne a merveille. Mais je dois faire ma solution en mode "client-serveur".

L'idée de faire ça en ClickOnce ou en WPF Browser m'a traversé l'esprit, mais je ne pense pas que ça apporterai une solution à mon problème.

Pour les technos ça sera en .NET 4.5, WPF et WCF.

Sûrement du MVVM car WPF et en plus je veux des tests unitaires, mais je t'avoue ne pas être un expert en MVVM.... Mais j'y travaille...

Je vais pas le dire à chaque fois ne t'inquiète pas, mais merci de prendre du temps pour me donner ton point de vue !

[DotNetMatt]

Ok, est-ce que tu connais Managed Extensibility Framework (MEF) ? Je pense que ça pourra t'intéresser.

[Ilaoet]

Ok, est-ce que tu connais Managed Extensibility Framework (MEF) ? Je pense que ça pourra t'intéresser.

Non je ne connais pas. Je vais regarder ça. Merci