2013-12-07 3 views
0

Я думаю, что я нахожусь в пути, чтобы, наконец, разыграть MVVM. Я просто смотрел на ситуацию, в которой я оказался, и мне интересно, следует ли мне объединить два моих слоя. Я в настоящее время имеют структуру, как это:У меня слишком много слоев WPF здесь?

  1. модели домена (в виде отдельного проекта .net)
  2. WPF стороне «модели», которая моделирует доменные обертка и отслеживать состояние грязного
  3. WPF ViewModels
  4. Просмотров

Вопрос заключается в том, следует ли мне комбинировать 2 и 3. Прямо сейчас # 2 - это слой, который передается моим посредником, чтобы облегчить все режимы просмотра, зная, какой документ в настоящее время открыт. Но я думаю, что мой код для 2 и 3 слишком похож и на данный момент является ненужным дублированием.

Пример:

// in layer 2, class ProjectDocument 
// Project is an instance of the domain model 
public string Name 
{ 
    get { return Project.Name; } 
    set 
    { 
     if (Project.Name == value) return; 
     Project.Name = value; 
     Dirty = true; 
    } 
} 

// in layer 3, class ProjectSettingsViewModel 
// _project is a ProjectDocument 
public string Name 
{ 
    get { return _project.Name; } 
    set 
    { 
     _project.Name = value; 
     OnPropertyChanged("Name"); 
    } 
} 

Увидев, что меня поразило, как ненужные. Так что я должен их объединить? С одной стороны, он удалит много избыточного кода, и у меня будет меньше мест для обновления при изменении вещей. С другой стороны, я мог бы возложить на один класс слишком большую ответственность, а также, кажется, нецелесообразно передавать реальный ViewModel другим виртуальным машинам через посредство моего посредника. ProjectSettingsViewModel не использовал бы половину полей на ProjectDocument, если бы они были объединены.

Возможно, я смотрю на это неправильно. Есть ли лучший способ уменьшить дублирование, сохраняя при этом отдельные обязанности?

ответ

0

У меня есть master viewmodel, который обрабатывает состояния приложения, такие как открытие документа/вкладки/окна, и у меня есть служба ISettingssService для других глобальных потребностей. Передача одной модели просмотра в другую не рекомендуется, и вы можете подумать о создании службы am iSettings, которая может быть введена в области просмотра, тогда модели просмотра могут взаимодействовать с «глобальными» настройками, но режимы просмотра все еще развязаны, поскольку они не зависят от другой модели viewmodel ,

Итак, я бы не стал их комбинировать. Либо у меня будет словарь документов, который может быть открыт в главной модели с текущим открытым свойством doc или переместить эту логику в сервис/интерфейс, который будет использоваться каждой моделью просмотра.

Надеюсь, это поможет.

Смежные вопросы