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

Question

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

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

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

Answer 1

Исходя из моего личного опыта, это надежный подход:

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

Тем не менее, ООП-зилоты будут утверждать, что вам не следует использовать классическую банду из четырех синглтонов (со статическим свойством экземпляра), а DI-синглтон, созданный объектКонтейнером 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 знать время жизни модели, что упрощает модульное тестирование.

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