Comment gérer l'injection de dépendance dans un WPF/MVVM application

Dans votre question, vous définissez la valeur de la DataContext propriété de la vue dans le XAML. Cela nécessite que votre vue-modèle possède un constructeur par défaut. Cependant, comme vous l'avez remarqué, cela ne fonctionne pas bien avec l'injection de dépendance où vous voulez injecter des dépendances dans le constructeur.

Donc vous ne pouvez pas définir la DataContext de la propriété dans le code XAML. Au lieu de cela vous avez d'autres alternatives.

Si l'application est basée sur une simple vue hiérarchique de modèle, vous pouvez construire la totalité de la vue-modèle de hiérarchie au démarrage de l'application (vous devrez supprimer le StartupUri bien de la App.xaml fichier):

public partial class App {

  protected override void OnStartup(StartupEventArgs e) {
    base.OnStartup(e);
    var container = CreateContainer();
    var viewModel = container.Resolve<RootViewModel>();
    var window = new MainWindow { DataContext = viewModel };
    window.Show();
  }

}

Ceci est basé autour d'un objet graphique de la vue-des modèles à la racine du RootViewModel mais vous pouvez également injecter une partie de la vue-modèle usines en vue parent-modèles leur permettant de créer de nouvelles vue d'enfant-les modèles de l'objet graphique n'a pas à être fixé. Cela aussi nous l'espérons répondre à votre question suppose que j'ai besoin d'une instance de SomeViewModel de mon cs code, comment dois je faire?

class ParentViewModel {

  public ParentViewModel(ChildViewModelFactory childViewModelFactory) {
    _childViewModelFactory = childViewModelFactory;
  }

  public void AddChild() {
    Children.Add(_childViewModelFactory.Create());
  }

  ObservableCollection<ChildViewModel> Children { get; private set; }

 }

class ChildViewModelFactory {

  public ChildViewModelFactory(/* ChildViewModel dependencies */) {
    //Store dependencies.
  }

  public ChildViewModel Create() {
    return new ChildViewModel(/* Use stored dependencies */);
  }

}

Si votre demande est plus dynamique dans la nature et peut-être est basé autour de la navigation, vous aurez à crochet dans le code qui effectue la navigation. Chaque fois que vous accédez à un nouveau point de vue vous avez besoin pour créer une vue de modèle (à partir du conteneur d'injection de dépendances), la vue elle-même et de définir les DataContext de l'afficher à la vue-modèle. Vous pouvez le faire d'abord la vue de où vous choisissez une vue (modèle basé sur une vue ou vous pouvez le faire vue-modèle premier d'où la vue-modèle détermine vue de leur utilisation. Un MVVM framework fournit cette fonctionnalité de la touche avec une certaine façon pour vous de brancher votre conteneur d'injection de dépendances dans la création de modèles mais vous pouvez également mettre en place vous-même. Je suis un peu vague ici, car en fonction de vos besoins, cette fonctionnalité peut devenir assez complexe. C'est l'une des fonctions de base que vous obtenez à partir d'un framework MVVM mais rouler votre propre dans une application simple vous donnera une bonne compréhension de ce que MVVM cadres de fournir sous le capot.

Par ne pas être en mesure de déclarer la DataContext dans le code XAML de vous faire perdre au moment de la conception de soutien. Si votre vue-modèle contient quelques données, il apparaît lors de la conception du temps qui peut être très utile. Heureusement, vous pouvez utiliser les attributs de conception également dans WPF. Une façon de le faire est d'ajouter les attributs suivants à l' <Window> élément ou <UserControl> en XAML:

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
mc:Ignorable="d"
d:DataContext="{d:DesignInstance Type=local:MyViewModel, IsDesignTimeCreatable=True}"

La vue-modèle type doit avoir deux constructeurs, la valeur par défaut pour les données de conception et un autre pour l'injection de dépendances:

class MyViewModel : INotifyPropertyChanged {

  public MyViewModel() {
    //Create some design-time data.
  }

  public MyViewModel(/* Dependencies */) {
    //Store dependencies.
  }

}

En faisant cela, vous pouvez utiliser l'injection de dépendance et de conserver une bonne conception de la prise en charge au moment.

- Je aller pour une "première vue", où je passe de la vue-modèle à l'affichage du constructeur (dans le code-behind), qui est affectée au contexte de données, par exemple

public class SomeView
{
    public SomeView(SomeViewModel viewModel)
    {
        InitializeComponent();

        DataContext = viewModel;
    }
}

Cela remplace votre XAML approche.

- Je utiliser le Prisme cadre pour gérer la navigation - lorsque certaines demandes de code d'un point de vue particulier être affiché (par "navigation"), l'Prisme permettra de résoudre ce point de vue (interne, à l'aide de l'application de la DI-cadre); le DI-cadre permettra à son tour de résoudre toutes les dépendances que le point de vue (la vue modèle dans mon exemple), puis résout son dépendances, et ainsi de suite.

Choix de DI-cadre est à peu près inutile comme ils le font tous essentiellement la même chose, c'est à dire vous vous inscrivez à une interface (ou un type) ainsi que le type de béton que vous voulez le cadre d'instancier quand il trouve une dépendance de l'interface. Pour l'enregistrement, j'ai utiliser du Château de Windsor.

Prisme de navigation faut s'habituer, mais c'est très bon une fois que vous obtenez votre tête autour de lui, vous permettant de composer votre application à l'aide de différents points de vue. E. g. vous pouvez créer un Prisme de la "région" sur votre fenêtre principale, puis en utilisant le Prisme de navigation vous permettrait de passer d'une vue à l'autre dans cette région, par exemple, que l'utilisateur sélectionne les éléments de menu ou quoi que ce soit.

Vous pouvez prendre un coup d'oeil à l'un des frameworks MVVM comme MVVM Light. J'ai aucune expérience de ces ne peut donc pas commenter sur ce qu'ils aiment utiliser.

Utiliser le Managed Extensibility Framework.

[Export(typeof(IViewModel)]
public class SomeViewModel : IViewModel
{
    private IStorage _storage;

    [ImportingConstructor]
    public SomeViewModel(IStorage storage){
        _storage = storage;
    }

    public bool ProperlyInitialized { get { return _storage != null; } }
}

[Export(typeof(IStorage)]
public class Storage : IStorage
{
    public bool SaveFile(string content){
        //Saves the file using StreamWriter
    }
}

//Somewhere in your application bootstrapping...
public GetViewModel() {
     //Search all assemblies in the same directory where our dll/exe is
     string currentPath = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
     var catalog = new DirectoryCatalog(currentPath);
     var container = new CompositionContainer(catalog);
     var viewModel = container.GetExport<IViewModel>();
     //Assert that MEF did as advertised
     Debug.Assert(viewModel is SomViewModel); 
     Debug.Assert(viewModel.ProperlyInitialized);
}

En général, ce que vous voulez faire est d'avoir une classe statique et d'utiliser le Modèle de Fabrique pour vous fournir un conteneur global (mise en cache, natch).

Que pour la façon d'injecter le point de vue des modèles, vous pouvez injecter de la même façon que vous injectez tout le reste. Créer une importation constructeur (ou mettre une instruction d'importation sur une propriété/domaine) dans le code-behind du fichier XAML, et dites-lui d'importer le modèle de vue. Puis lier votre Window's DataContext à la propriété. Votre racine objets vous fait sortir du container vous-même sont généralement composées Window objets. Juste ajouter des interfaces pour les classes de fenêtre, et de les exporter, puis saisir à partir du catalogue comme ci-dessus (dans l'App.xaml.cs... c'est le WPF fichier de bootstrap).

Je vous suggérons d'utiliser le ViewModel - Première approche
https://github.com/Caliburn-Micro/Caliburn.Micro

voir:
https://caliburnmicro.codeplex.com/wikipage?title=All%20About%20Conventions

utilisation Castle Windsor comme conteneur IOC.

Toutes Les Conventions

L'une des principales caractéristiques de Caliburn.Micro est manifeste dans sa capacité à éliminer la nécessité pour la chaudière de la plaque de code, en agissant sur une série de conventions. Certaines personnes aiment les conventions et certains les détestent. C'est pourquoi CM conventions sont entièrement personnalisables et peuvent même être complètement éteint si elle n'est pas désirée. Si vous allez utiliser les conventions, et depuis ils sont activés par défaut, il est bon de savoir ce que ces conventions sont et comment ils fonctionnent. C'est le sujet de cet article.
Vue De La Résolution (ViewModel-Première)

Bases

La première convention, vous êtes susceptible de rencontrer lors de l'utilisation de CM est liée à la résolution de vues. La présente convention n'affecte les ViewModel-Première les domaines de votre application. Dans le ViewModel-tout d'Abord, nous avons déjà ViewModel que nous avons besoin de rendre à l'écran. Pour ce faire, CM utilise un simple modèle de nommage pour trouver un UserControl1 qu'il est conseillé de lier le ViewModel et de l'affichage. Alors, quel est ce modèle? Nous allons juste prendre un coup d'oeil à ViewLocator.LocateForModelType à savoir:

public static Func<Type, DependencyObject, object, UIElement> LocateForModelType = (modelType, displayLocation, context) =>{
    var viewTypeName = modelType.FullName.Replace("Model", string.Empty);
    if(context != null)
    {
        viewTypeName = viewTypeName.Remove(viewTypeName.Length - 4, 4);
        viewTypeName = viewTypeName + "." + context;
    }

    var viewType = (from assmebly in AssemblySource.Instance
                    from type in assmebly.GetExportedTypes()
                    where type.FullName == viewTypeName
                    select type).FirstOrDefault();

    return viewType == null
        ? new TextBlock { Text = string.Format("{0} not found.", viewTypeName) }
        : GetOrCreateViewType(viewType);
};

Nous allons ignorer le “contexte” de la variable au premier abord. Pour dériver le point de vue, nous faisons une hypothèse que vous utilisez le texte “ViewModel” dans le nommage de vos machines virtuelles, afin que nous venons de changer l'état de “Vue” partout où nous le trouvons en supprimant le mot “Modèle”. Cela a pour effet de modifier à la fois les noms de type et les espaces de noms. Donc Viewmodel.CustomerViewModel deviendrait points de Vue.CustomerView. Ou si vous êtes l'organisation de votre application en fonction: CustomerManagement.CustomerViewModel devient CustomerManagement.CustomerView. J'espère que c'est assez simple. Une fois que nous avons le nom, nous avons alors à la recherche pour les types avec ce nom. Nous sommes la recherche de toute l'assemblée, vous avez exposé à la CM comme consultable via AssemblySource.Exemple.2 Si nous trouvons le type, nous créons une instance (ou en obtenir un à partir du conteneur IoC si il est enregistré) et le retourner à l'appelant. Si nous n'avons pas trouver le type, nous générer une vue avec un “non trouvé” message.

Maintenant, revenir à ce “contexte” de la valeur. C'est de cette manière CM prend en charge de multiples points de Vue au cours de la même ViewModel. Si un contexte (en général une chaîne ou un enum) est fourni, nous faisons une poursuite de la transformation du nom, de la fonction de cette valeur. Cette transformation suppose que vous avez un dossier (espace de noms) pour les différents points de vue en supprimant le mot “Vue” à partir de la fin et en ajoutant le contexte de la place. Donc, étant donné un contexte de “Maître” notre Viewmodel.CustomerViewModel deviendrait points de Vue.Client.Maître.