MVVM - injection de modèle dans viewmodels vs obtention de modèle via singleton

Question

Dans mon application, le modèle est un ensemble de données représentant une base de données et il ne devrait donc y avoir qu'un seul objet modèle à tout moment de l'exécution de l'application. Actuellement, il est créé lorsque l'application démarre et est stocké en tant que propriété dans la classe d'application. Les viewmodels reçoivent une référence à l'ensemble de données/au modèle via leurs constructeurs. Étant donné qu'il ne peut y avoir qu'un seul ensemble de données, serait-il préférable d'implémenter une classe singleton qui créera/renverra l'ensemble de données et fera en sorte que viewmodels en obtienne la référence (y a-t-il des problèmes avec cette approche)?

Merci, James

Answer 1

De mon expérience personnelle, c'est une approche Rocksolid:

1. vous empêchent instanciation de plus d'une instance de DataSet
2. Vous avez globalement disponible, ce qui est ce que vous voulez et rend la vie facile

Cependant, POO-Zélotes argueront que vous ne devriez pas utiliser un gang classique de quatre Singleton (avec la propriété statique instance), mais un DI Singleton, un objet qui est créé par le conteneur DI une seule fois, puis passé partout.

Personnellement, je pense que c'est un compromis: le GoF Singleton est facile à utiliser et simple. Je n'ai jamais eu un cas où je devais le remplacer ou l'accès à la base de données en général. J'ai une interface pour l'accès à la base de données et en cas de besoin je pourrais changer l'implémentation dans le Singleton (et l'améliorer, de sorte que cela soit possible même pendant l'exécution). Il peut également vous faire économiser beaucoup de code standard, mais gardez à l'esprit que votre modèle est alors très étroitement couplé à la base de données et ne peut pas exister sans elle. Le seul avantage des choses DI que je peux voir est que vous pouvez le configurer à partir d'une config externe car je doute que la gestion du cycle de vie de votre accès à la base de données changera, ce qui serait l'autre avantage de DI. Et votre ObjectModel pourrait être maintenu propre à long terme (plus pour les grands projets). Personnellement, j'aime utiliser cette implémentation générique de Singleton. Certains fétichistes d'objets diront que c'est plus un wrapper qu'un singleton, mais cela fait du bon travail et vous permet même de garder vos ObjectModels ("par opposition à ViewModels", ne vous méprenez pas) purs comme vous n'en avez pas besoin pour les mettre en œuvre singletons avec les membres statiques:

public class Singleton<T> where T : class { 
    static object SyncRoot = new object(); 
    static T instance; 
    public static T Instance { 
     get { 
      if (instance == null) { 
       lock (SyncRoot) { 
        if (instance == null) { 
         ConstructorInfo ci = typeof(T).GetConstructor(BindingFlags.NonPublic | BindingFlags.Instance, null, Type.EmptyTypes, null); 
         if (ci == null) { throw new InvalidOperationException("class must contain a private constructor"); } 
         instance = (T)ci.Invoke(null); 
        } 
       } 
      } 
      return instance; 
     } 
    } 
} 

http://www.sanity-free.com/132/generic_singleton_pattern_in_csharp.html

Answer 2

Ayant que le constructeur va le rendre plus flexible. En fait vous pouvez implémenter Singleton et passer la même instance de singleton tout le temps ou obtenir le DI cadre pour le garder comme singleton si vous en utilisez un. Cela empêchera ViewModel d'avoir connaissance de la durée de vie du modèle, ce qui facilite les tests unitaires. Une chose avec les Datasets cependant - ils ne sont pas vraiment un modèle car ils sont lâches. Même si vous devez utiliser Dataset, j'aurais créé des modèles de classe d'entité et les aurais traduits. Le jeu de données n'est pas DDD.