MVVM - модель ввода в модели просмотра по сравнению с получением модели через singleton

Question

В моем приложении модель представляет собой набор данных, представляющий базу данных, и поэтому в любой момент выполнения приложения должен быть только один объект модели. В настоящее время это создается, когда приложение запускается и хранится как свойство в классе приложения. Модели viewmodels получают ссылку на набор данных/модель через их конструкторы.

Увидев, что может быть только один набор данных, было бы лучше реализовать одноэлементный класс, который будет создавать/возвращать набор данных, а также, чтобы модели viewmodels получили от них ссылку (есть ли какие-либо проблемы с этим подходом)?

Спасибо, Джеймс

Answer 1

Из моего личного опыта, это rocksolid подход:

1. Вы предотвратить создание экземпляра более одного экземпляра Dataset
2. Вы его доступным во всем мире, которая является то, что вы хотите, и делает жизнь проще

Однако ООП-Фанатики будут утверждать, что вы не должны использовать классическую Банда четырех Singleton (со статическим Instance собственности), но в DI Singleton, объект, который создается с помощью DI контейнер только один раз, а затем проходил повсюду.

Лично я считаю, что это компромисс: GoF Singleton прост в использовании и прост. У меня никогда не было случая, когда я должен был заменить его или доступ к базе данных в целом. У меня есть интерфейс для доступа к базе данных, и при необходимости я могу изменить реализацию в Singleton (и улучшить ее, чтобы это было возможно даже во время выполнения). Он также может сэкономить вам много кода шаблона, но имейте в виду, что ваша модель тогда очень тесно связана с базой данных и не может существовать без нее.

Единственное преимущество материала DI, которое я вижу, это то, что вы можете настроить его из внешней конфигурации, поскольку я сомневаюсь, что управление жизненным циклом доступа к базе данных будет когда-либо изменено, что будет другим преимуществом DI. И ваш ObjectModel может быть очищен в долгосрочной перспективе (плюс для больших проектов).

Мне лично нравится использовать эту общую реализацию Singleton. Некоторые фетишисты-объекты снова будут утверждать, что это скорее обертка, чем синглтон, но она хорошо справляется и даже позволяет вам сохранять свои объекты ObjectModels («в отличие от ViewModels», не ошибайтесь) чистыми, поскольку вам не нужно реализовать их как одиночка со статическими членами:

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

Имея, что конструктор сделает его более гибким. Фактически вы можете реализовать Singleton и передать один и тот же экземпляр singleton все время или получить DI framework, чтобы сохранить его как одноэлементный, если вы используете его.

Это не позволит вашему ViewModel знать о времени жизни модели, что упрощает модульное тестирование.

Одна вещь с наборами данных, хотя - они на самом деле не модель, так как они свободны. Даже если вам нужно использовать Dataset, я бы создал модели класса сущностей и перевел их. Набор данных не является DDD.