ВМ разрешается дорого? MVVM Autofac

Question

У нас есть приложение WPF MVVM, в качестве контейнера DI IO C мы используем Autofa c. Мы регистрируем модели представления и разрешаем их во время выполнения.

Я понял, что все конструкторы всех наших моделей представления, субмоделей и суб-представлений работают в начале программы. Как и следовало ожидать, я догадываюсь.

Нашим vms обычно нужно получать данные из базы данных, поэтому мы используем метод «поддельного конструктора» LoadAsyn c (), где выполняется тяжелая работа.

Модель представления обычно выглядит следующим образом

public class MyVm : BaseViewModel {
    //... lots of fields and properties

    public MyVm(SubVm1 sub1, SubVm2 sub2, Repository1 repo1, SomeService svc){
         this.sub1 = sub1;
         this.sub2 = sub2;
         this.repo1 = repo1;
         this.svc = svc;
    }
}

Я пытаюсь решить, нравится ли мне эта настройка.

Я думал о ViewModelLocator, но тогда я не могу легко идентифицируйте зависимости класса через конструктор. Но я смогу отложить создание объекта до тех пор, пока не понадобится subVm.

Я думал о том, чтобы просто ввести фабричный метод, сохранить задержку, сохранить информацию. Легко настроить с помощью autofa c, но мне это кажется странным.

Все сводится к тому, как дорого создавать экземпляры этих типов классов при запуске. Я прочитал, что создание объекта действительно дешево в C#, но все равно дешево, если у меня много полей и свойств? Что если мы получим сотни моделей представления, которые все создаются в начале приложения?

Answer 1

Итак, на моей работе у нас есть C# wpf-приложение. У нас есть последовательность запуска:

• База данных инициализации (EF6)
• регистрация всех служб
• Регистрация всех моделей представления

где Viewmodels могут быть вложенными.

Viewmodels состоят из конструкции модели представления. В этом подходе viewmodel также создает любые дочерние viewmodels, например, для datagrids, управляет подобным образом.

Затем у нас есть механизм с призмой, где у нас есть 2 обработчика на каждую viewmodel для OnNavigatedTo и * 1016. * которые вызываются, когда пользователь переключается на экран или с экрана. В этих функциях находится большая часть логов обновления и очистки c. Таким образом, ctor создаст менеджера, который взаимодействует с logi c, и тогда только в нашем onNavigateTo мы осуществляем фактическую выборку данных.

Создание объекта чрезвычайно быстро, и, поскольку мы склонны сохранять Вдали от долгосрочных функций (вызовы базы данных и т. д. c) в большинстве случаев примерно в 20 раз является инициатором наших услуг.

Мы создаем около 15 экранов для модулей, каждый из которых содержит около 5- 10 панелей (так что они вложены в модели нашего экрана), каждая из которых может иметь около 1-10 элементов управления. Затем у нас есть еще около 30 дополнительных экранов для других вещей.

Таким образом, у нас есть немало моделей представления, которые могут быть довольно большими, но поскольку большинство ресурсоемких элементов там не расположено, нагрузка довольно мала .

Я не знаю, отвечает ли это на ваш вопрос, но это должно дать вам лучшее понимание, и я надеюсь, что это поможет.

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

Просто запомните; не оптимизируйте перед измерением, а также убедитесь, что у вас есть хорошее представление о том, что является приемлемым для клиента с точки зрения времени запуска.