Discussion :

[CaptainChoc]

Bonjour à tous

Voilà j’essaie d'utiliser MEF et MVVM... pour l'instant j'essaie de faire quelque chose de simple mais malgré les quelques tutos que j'ai pu trouver je ne comprends pas bien le principe...

Voilà j'ai dans mon appli principale, une treeview avec un noeud racine (jusque là ok...)

Je veux avoir des modules qui vont m'ajouter des noeuds enfant à mon noeud racine. (en sachant que pour des raisons pratiques, j'aimerai que tous les viewmodel des noeuds "module" hérite de ma classe :

Code c# :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
   public abstract class TreeViewNodeViewModel : ViewModelBase
    {
        public TreeViewNodeViewModel Parent { get; set; }
 
        protected bool _isSelected = false;
        public bool IsSelected
        {
            get { return this._isSelected; }
            set
            {
                if (value != this._isSelected)
                {
                    this._isSelected = value;
                    RaisePropertyChanged("IsSelected");
                }
 
                if (TreeView != null && this._isSelected)
                {
                    TreeView.SelectedItem = this;
                }
            }
        }
 
        protected ObservableCollection<TreeViewItemViewModel> _nodes;
        public ObservableCollection<TreeViewItemViewModel> Nodes
        {
            get
            {
                return this._nodes;
            }
        }
 
        protected string _displayName;
        public string DisplayName
        {
            get
            {
                return this._displayName;
            }
            set
            {
                this._displayName = value;
                RaisePropertyChanged("DisplayName");
            }
        }
    }

et voilà comment j'affiche mon treeview :

Code xaml :

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

1
2
3
4
5
6
7
8
 
 <TreeView HorizontalAlignment="Stretch" VerticalAlignment="Stretch" ItemsSource="{Binding TreeView1.RootNode, Mode=TwoWay}">
            <TreeView.Resources>
               <HierarchicalDataTemplate DataType="{x:Type vm:TreeViewNodeViewModel}" ItemsSource="{Binding Nodes}" >
                        <TextBlock Text="{Binding DisplayName}" />
                </HierarchicalDataTemplate>
            </TreeView.Resources>
        </TreeView>

Et c'est là que je ne vois pas comment continuer... comment adapter la classe ci dessus pour qu'elle soit compatible MEF et donc "utilisable" par mes modules ?

Si vous avez des tutos sur MEF, je suis preneur...

Merci de votre aide

Edit : 'ai regardé ce tuto : http://www.studentguru.gr/blogs/grne...using-mef.aspx et ce qui me choque c'est qu'il n'utilise pas "Import" ou "Export"... juste un projet "Contract" qu'il réutilise dans tous ces modules/plugins... qu'en pensez vous ?

[Invité]

Salut,

En voyant ta classe, je me dis que t'as même pas commencé à utiliser MEF. Comme tu l'as MEF t'oblige à utiliser des attributs Import (pour les classes qui ont besoin de modules) et Export (pour les classes qui doivent être exportées en tant que module ou plugin). Les Contrats sont là même pour limiter le couplage entre les exports et les imports. Ce sont ces contrats que tu utilisent en combinaison avec les attributs Export pour pouvoir importer un module.

Bref je te renvoie vers ce lien qui a traduit la documentation sur MEF.

Bonne lecture.

[CaptainChoc]

Merci de ta réponse et en effet je ne suis qu'au tout début de MEF... mais je ne comprends pas certaines choses... je regarde le tuto de Julien Corioland intitulé [.NET 4.0] Première application MEF : Managed Extensibility Framework – UPDATE MEF Preview 6 (j'ai trouvé le lien du tuto dans la doc que tu m'as donné).

Pouquoi devoir créer une interface "IModuleMetaData"... pour importer les métadonnées vous allez me dire... mais pourquoi ??? ne peut on pas directement y acceder ? et est ce que ça veut dire que toutes les métadonnées doivent se trouver dans ma classe "IModuleMetaData" ou seulement celles utilisées par mes modules ?..

Si j'ai bien compris, dans mon exemple, pour mes modules, j'aurai 2 class : PluginViewModel et IPluginViewModelMetaData...

avec :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public class PluginViewModel : TreeViewNodeViewModel 
{
???
}
 
public interface IPluginViewModelMetaData
    {
        public TreeViewItemViewModel Parent { get; set; }
        public bool IsSelected { get; set; }
        public string DisplayName { get; set; }
        public ObservableCollection<TreeViewNodeViewModel> Nodes { get; set; }
 }

Puis dans le model view qui va afficher mon treeview, j'aurai :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public class TreeViewViewModel : TreeViewNodeViewModel 
{
    ObservableCollection<Lazy<PluginViewModel , ITreeViewPluginMetaData>>  TVPlugins; 
 
// ...
 
    public void loadTreeView()
    {
        foreach(var node in TVPlugins)
        {  
                TreeViewPlugin plg = node as TreeViewPlugin;
                this.Nodes.add(plg)
        }
    }
 
}

et dans mon module :

Code :

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

1
2
3
4
5
6
7
 
public class Module1ViewModel : PluginViewModel, IPluginViewModelMetaData
{
 // ...
   public  DisplayName { get { return "Module1"} }
  // ...
}

mais ça me parait compliqué, je dois faire n'importe quoi..., je ne sais plus qui fait quoi et qui charge qui...

[Invité]

Pour la question sur la création de la classe Metadata tu y es pas obligé. Je ne sais pas si t'as bien lu le document que je t'ai fourni dans le lien de mon post précédent mais les classes métadonnées sont juste créées et recommandées pour que tu ais un objet plus facile à manier et ne pas te pas te taper la recherche de la valeur d'une métadonnée par l'intermédiaire de sa clef qui est une chaîne de caractères (source d'erreur) dans le dictionnaire de métadonnées.

Si tu ne veux pas utiliser les métadonnées à travers des classes personnalisées alors c'est simple utilises le dictionnaire qui t'est exposé.

[CaptainChoc]

Ah donc si je comprends bien, j'ai ma classe normal (avec les métadonnées, les accesseurs...) et mon interface qui ne contient que la structure (qui est là juste pour m'aider)...

En fait MEF n'est finalement que là pour charger en direct les assemblies...

Cer si on regarde le lien du tuto que moi j'ai donnée, il n'utilise pas de [import]/[export] ou de classe contenant les métadata...

Qu'en pensez vous ?

[Invité]

Ah donc si je comprends bien, j'ai ma classe normal (avec les métadonnées, les accesseurs...) et mon interface qui ne contient que la structure (qui est là juste pour m'aider)...

Oui c'est globalement ça. Ton interface est juste là pour diminiuer le couplage entre les import/export est ton application.

En fait MEF n'est finalement que là pour charger en direct les assemblies...

C'est aussi grâce à MEF que tu définis tes imports et tes exports mais pas seulement de les charger.

Cer si on regarde le lien du tuto que moi j'ai donnée, il n'utilise pas de [import]/[export] ou de classe contenant les métadata...

Bah je viens de revérifier et ça parle bien des imports et des exports plus précisément ici.

[Nathanael Marchand]

Olivier Dahan, référence Silverlight Francophone, a écrit un article très très complet sur le sujet:
http://www.e-naxos.com/Blog/post/201...echarger).aspx

[CaptainChoc]

Ok j'ai mieux saisie les fonctionnalités et le fonctionnement de MEF... je vais l'adapter à mon projet... mais j'aurai besoin juste d'une précision, dans mon cas, le "contrat" ne serai pas une interface mais ma classe "TreeViewNodeViewModel" (car j'aimerai que tous mes modules aient déjà certaines fonctionnalités... est ce que je reste dans la philosophie MEF ?)

Par contre je n'ai pas trouvé si il était possible de ne charger que certaines assemblies... qui serai déclaré dans le fichier App.config par exemple (je crois que PRISM propose quelque chose qui y ressemble).

Par exemple, pour x ou y raison, je ne veux activer que 3 des modules que j'ai dans mon répertoires "plugin" et j'aimerai un truc genre, dans mon fichier App.config, je déclare le nom des l'assembly... et dans mon appli ne charger que les assemblies qui sont déclarées...

Une idées si cela est réalisable/prévu avec MEF ? ou s'il faut faire soit même un espèce de filtre sur les assemblies présents ?

Merci

[BreizhYann]

Bonjour CaptainChoc,

les interfaces déclarent ton contrat. Le code métier est déclarés dans tes assembly "add-on". L'application hote ne fait qu'appeler des fonctionnalités de ces assemblies. Tu peux tout à fait obliger le créateur d'add-on à utiliser des TreeViewNodeViewModel grâce à l'interface. A partir de là tu est sur de la compatibilité entre ton appli et ton addon.

Quant à charger certaines assembly en les definissant dans l'app.config je ne vois plus bien l'interet de MEF là dedans. du coup il serait impossible de créer des extensions (à moins que je ne saisisse pas quelque chose)

Pour filtrer les assembly, lorsque tu crée ton DirectoryCatalog, tu peux appliquer des filtres.

cordialement

[CaptainChoc]

Tous les exemples qu'on peu voir sur MEF sont à chaque "charger tous les assemblies d'un répertoires"... j'aimerai (si possible) ne charger que "quelques" assemblies, ceux qui seraient définis dans mon fichier config :
par exemple, mon appli a 3 modules, je l'installe sur 2 machines :
- 1 machine avec tous les modules
- une autre avec seulement 1 module.

Pour m'éviter d'avoir a faire 2 msi, j'installe mon appli sur les 2 et dans le fichier config j'active et je désactive les modules...

Ensuite, tu écris

L'application hote ne fait qu'appeler des fonctionnalités de ces assemblies. Tu peux tout à fait obliger le créateur d'add-on à utiliser des TreeViewNodeViewModel grâce à l'interface

La j'ai un peu de mal a comprendre en faite... l'interface servirai uniquement pour les métadata (pour l'autocompletion), sinon mon "add-on" dérivera directement de "TreeViewNodeViewModel", non ? ou j'ai encore raté quelque chose ?

[Invité]

Re bonjour,

Comme tu l'as dit MEF permet de charger des modules suivant un répertoire. Le catalogue te permettant de le faire est la classe DirectoryCatalog. Cette classe possède deux constructeurs. les deux constructeurs reçoivent le chemin du répertoire mais le deuxième reçoit en plus un pattern de recherche. Vu que tu ne veux pas charger tous les modules donc tu dois définir ton catalogue en utilisant le deuxième constructeur.

Exemple :
Supposons que nous ayons 3 modules dont les noms sont définis comme ça :

• ModuleComaptibleToutMachine.dll
• ModuleComaptibleToutMachine.dll
• ModuleSeulementMachineA.dll

Pour charger tous les modules alors tu feras appel au constructeur avec un seul argument. Pour charger par exemple que les modules dont la machine A a besoin alors tu instancieras ton catalogue comme suit :

Code C# :

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

1
2
 
DirectoryCatalog catalog = new DirectoryCatalog("chemin du repertoire", "*MachineA.dll");

En gros il faut que tu joues sur les patterns pour charger tes modules par conséquent tu dois fournir à ces derniers des noms qui te permettent d'avoir un pattern simple à utiliser en paramètre.

Si par contre les noms de tes modules ne sont pas explicites rien ne t'empêche de fournir le nom complet du module comme pattern du constructeur DirectoryCatalog.

Que tu passes par les patterns ou par les noms des modules, ces données doivent être dans ton fichier de configuration. Il faut pas oublier que s'il y a de N patterns ou modules spécifiques à charger tu créeras autant de Directory Catalog pour les charger.

[BenoitM]

Tiens CaptainChoc
Bête question tu travailles sur quoi comme application?

Ca donne envie d'être dans ton projet :p

[BreizhYann]

Captain,

H2S84 a complété ma réponse sur le DirectoryCatalog. Quant à l'interface, elle garantie un contrat entre ton application coeur et un add-on.
En gros tu as une classe implémentant T exportée dans ton addon (à l'aide de l'attribut Export(typeof(T)) et dans ton application mère tu as une collection de T comportant l'attribut ImportMany(typeof(T)).

Du coup tu es sur que sur chaque objet de la classe x implémentant T tu peux appeler des méthodes de T.En appelant ces méthodes tu t'ajooutes des fonctionnalités de manière incrémentiel.

Mais toute l'implémentation des méthodes est réalisé dans tes dll externe.

Cordialement

[CaptainChoc]

Projet Top Secret
Nan sérieux c'est une ancienne appli que j'avais faite en WinForm (sans module) qui permet de gérer des métadonnée sur des images, générer un ppt avec ces métadonnées et d'autres trucs du genre...

Mais j'ai encore du mal avec MEF...
Revenons a mon exemple que je simplifie...
J'ai une fenetre avec un TreeView vide.
Lorsque je clique sur un bouton/menu de mon interface, je voudrais ajouter un noeud racine et je veux pouvoir charger les modules (et leur passer des paramètres) qui vont ajouter des noeuds enfants à ma racine.


Ma classe dont doit hériter tous les noeuds de ma treeview...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
namespace MonAppli.Host.Contract
{
	public abstract class TreeViewNodeViewModel : ViewModelBase
	{
		public string DisplayName {...};
		public string MonObjet MonObj;
 
		public ObervableCollection<TreeViewNodeViewModel> Nodes;
		...
	}
 
	public interface ITreeViewNodeMetaData
	{
		string DisplayName {get; set;}
                string MonObjet MonObj;
	}
}

Le modelView du noeud racine : c'est lui qui va charger les ViewModel des modules (et les datatemplates feront le reste)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
namespace MonAppli.Host
{
	public class RootNodeViewModel : TreeViewNodeViewModel
	{
	// ajout de typeof(TreeViewNodeViewModel)
		[ImportMany(typeof(TreeViewNodeViewModel))]
		public IEnumerable<Lazy<TreeViewNodeViewModel, ITreeViewNodeMetaData>> Modules;
 
		public RootNodeViewModel(MonObjet obj)
		{
			this.MonObj = obj;
 
			DisplayName = "Racine";
			DirectoryCatalog catalog = new DirectoryCatalog("chemin du repertoire");
			var container = new CompositionContainer(catalog);
			container.ComposeParts(this);
 
			foreach(var module in this.Modules)
			{
				TreeViewNodeViewModel nodeViewModel = module.Value as TreeViewNodeViewModel
				nodeViewModel.MonObj = obj;
				this.Nodes.add(nodeViewModel);
			}
		}
	}
}

Et enfin un exemple de module.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
using MonAppli.Host.Contract;
 
namespace MonAppli.Module1
{
	[Export(typeof(TreeViewNodeViewModel))]
	public class Module1ViewModel : TreeViewNodeViewModel, ITreeViewNodeMetaData
	{
		public RootNodeViewModel()
		{
		}
 
		public string DisplayName
		{
			get { return this.MonObj.toString() + " - Module1"; }
			...
		}
	}
}

Mais là j'avoue que mon interface MEtadata ne sert pas à grand chose...

Est ce que je suis dans le bon chemin ? c'est à dire que lorsque je le demanderai (clique sur un bouton, menu, ... et pas au chargement de l'appli), les modules pour mon treeview (ceux qui héritent de TreeViewNodeViewModel) seront chargés et affichés dans mon treeview sous le noeud racine ? Est ce qu'il me manque quelque chose ?

[BreizhYann]

ajoute un typeof de ton treenode sur ton importmany en revanche je ne sais pas si tu peux le faire avec une classe abstraite.
Si non ça me parait viable (lecture rapide)

[CaptainChoc]

j'ai du mal a comprendre a quoi sert "ITreeViewNodeMetaData" et imaginons que j'ai 3 boutons. A chaque bouton correspond un objet "MonObjet" différent.

Si je clique sur le bouton1, je veux avoir :
- racine
- bouton1 - Module 1

Si je clique sur le bouton2, je veux avoir :
- racine
- bouton2 - Module 1

Si je clique sur le bouton3, je veux avoir :
- racine
- bouton3 - Module 1

Mais comme j'ai mis le "chargement" des DLL et l'initialisation des modules dans le constructeur.
Dans ma commande qui change "MonObjet", je refais une boucle qui initialise la variable "MonObjet" des modules ?

[BreizhYann]

Le plus simple pour moi serait une interface par objet avec chaque classe qui implémente et l'interface spcéifique et l'interface metadata. Tu fait tes exports en te basant sur les interfaces spécifiques de chaque objet et basta.

Bon faut vérifier que ça marche mais ya pas de raisons(enfin je crois pas^^)
le problème c'est que pour ajouter des boutons à la volée... c'est mort faut obligatoirement implémenter le comportement d'une des interfaces présente

[Invité]

Ce que je te propose c'est d'oublier ton application pendant une journée et de lire les différents tutos proposés à travers ce thread et si possible faire une petite application toute simple pour bien appréhender le fonctionnement de MEF. Si après tout tu te rends compte que MEF ne répond pas à ta question rien ne t'interdit de changer de framework. Au cas où tu le saurais pas il y a plusieurs frameworks tels que Spring.Net, PRISM ou Unity qui permettent de créer une application modulaire.

Tu es sur un projet perso à ce que je sache donc rien ne t'empêche de tout les tester ces frameworks et ainsi avoir une idée globale.

[BenoitM]

Tu es sur un projet perso à ce que je sache donc rien ne t'empêche de tout les tester ces frameworks et ainsi avoir une idée globale.

Le temps?
Bon maintenant il s'embête peut-être beaucoup

[CaptainChoc]

Mon application, je l'ai déjà oublié, j'a également déjà refait tous les exemples "simple" et j'aurai aimé approfondir un peu plus...

Cependant, tous les tuto que j'ai lu, même s'ils sont très bien fait, n'expliquent pas pourquoi on fait les choses et comment elles fonctionnent réellement... par exemple je n'ai pas trouvé d'infos sur ne charger que les module qu'a un moment donnée et pas au lancement de l'appli (et n'en charger que quelques un). Là j'ai l'impression que MEF est une grosse boite noire, on met des import, export, metadonnees, ok, ça marche... mais personne ne sait vraiment pourquoi... (ou en tout cas personne n'explique les choses) et je voulais donc juste approfondir et faire quelque chose d'un peu plus complexe...