Разве производительность не сработает с инструментарием MVVM Light?

Question

Я использовал популярный инструментарий MVVM Light: здесь для создания приложений для Windows Phone, и у меня возник вопрос по поводу шаблона.Для каждой созданной страницы мы создаем новую модель представления, чтобы сохранить код в чистоте и способствовать разделению интересов.Однако конструктор ViewModelLocator содержит инстанцирование каждой модели представления.

Конструктор ViewModelLocator обычно выглядит следующим образом:

public ViewModelLocator()
    {
        ////if (ViewModelBase.IsInDesignModeStatic)
        ////{
        ////    // Create design time view models
        ////}
        ////else
        ////{
        ////    // Create run time view models
        ////}

        CreateMain();
        CreatePage2();
        CreatePage3();
        CreatePage4();
    }

Если приложение содержит несколько страниц, не будет создавать каждыйViewModel даже для тех представлений, которые могут никогда не потребоваться, вызывают проблемы с производительностью?

Я что-то здесь упускаю?

Answer 1

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

Это правда, что при кодировании WP7 через .Net, C #, Silverlight, XAML, DataBinding и MVVMLight вы вставляете много «накладных расходов» - и большая часть этих накладных расходов присутствует для удобства кодера, а не для выгоды пользователя.

Тем не менее, процессор WP7, видеопроцессор, быстрая оперативная память и быстрая память SolidState действительно очень быстрые - так что есть место для некоторых накладных расходов, и вы можете использовать эти платформы для создания восхитительных, отзывчивых приложений WP7.

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

Обычно, когда я измеряю, я обнаруживаю, что мои узкие места в производительности не соответствуют моим ожиданиям ... Я также обнаруживаю, что всегда есть компромиссы - например, Здесь вы можете быть обеспокоены тем, что компромиссный код Locator может выполняться медленнее, но более поздний код поиска может выполняться быстрее, поэтому навигация в приложении может быть быстрее за счет немного более медленного времени запуска.

Answer 2

Вам не нужно явно создавать объекты в конструкторе.Вы можете отложить их до первого доступа к ним.

public MainPageViewModel MainPage
{
  if(_mainPageViewModel == null)
  {
    _mainPageViewModel = CreateMain(); 
  }
  return _mainPageViewModel;
}

Во что бы то ни стало измерьте производительность, как сказал @Stuart, но, как правило, неплохо создавать только то, что вам нужно.Поэтому лучше было бы отложить создание до свойства get.

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