MVVM - RaisePropertyChanged превращая код в беспорядок - PullRequest
9 голосов
/ 31 марта 2010

Новичок в MVVM, так что прошу прощения за мое невежество.

Я думаю, что я правильно его использую, но я считаю, что моя ViewModel имеет слишком много из них:

RaisePropertyChanged("SomeProperty")

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

Я скучаю по тем дням, когда я мог просто пойти:

public int SomeInteger { get; private set;}

В эти дни я должен везде вставлять RaisePropertyChanged, иначе мой интерфейс не отражает изменений: (* ​​1011 *

Я делаю это неправильно или других людей раздражает чрезмерное количество магических струн и установщиков свойств старой школы?

Должен ли я использовать вместо этого свойства зависимостей? (Я сомневаюсь, что в любом случае это помогло бы увеличить код)

Несмотря на эти проблемы, я все еще думаю, что MVVM - это путь, поэтому я думаю, что это что-то.

Ответы [ 5 ]

12 голосов
/ 31 марта 2010

Взгляните на это Какое лучшее или наиболее интересное использование методов расширения вы когда-либо видели? .

В нем описываются метод расширения и вспомогательный метод, которые используются в моих классах Model и ViewModel для включения следующих строго типизированных (без магической строки) свойств.

private string _name;
public string Name
{
    get { return _name; }
    set { this.NotifySetProperty(ref _name, value, () => this.Name); }
}

Это примерно так просто, как я думаю, это может быть получено. Надеюсь, это поможет.

7 голосов
/ 31 марта 2010

Вы можете использовать атрибут NotifyPropertyChanged PostSharp. Тогда все, что вам нужно сделать, это поместить атрибут в класс и все. E.g.:

[NotifyPropertyChanged]
public class MyClass 
{
    public string MyProperty { get; set; }
}
4 голосов
/ 31 марта 2010

Это помогает взглянуть на вещи с другой точки зрения: это не сложные свойства .NET, а упрощенные свойства зависимостей.

Связываемые свойства модели представления в WPF не идентичны свойствам .NET, а являются своего рода хранилищем значений ключей.Если вы хотите облегченную альтернативу DependencyObject, у вас есть возможность реализовать это хранилище значений ключей, просто покупая вызов определенной функции в установщиках - на самом деле неплохо.Конечно, далеко не идеал, но ваша точка зрения, безусловно, несправедлива.

0 голосов
/ 05 ноября 2013

Это поможет: "Вид магии" Без усилий INotifyPropertyChanged

[http://visualstudiogallery.msdn.microsoft.com/d5cd6aa1-57a5-4aaa-a2be-969c6db7f88a][1]

как пример для добавления его к одному свойству:

[Magic] 
public string Name { get { return _name; } set { _name = value; } } 
string _name;

Другой пример добавления его ко всем свойствам класса:

[Magic] 
public class MyViewModel: INotifyPropertyChanged 
{ 
  public string Name { get; set; } 
  public string LastName { get; set; } 
  ..... 
}
0 голосов
/ 16 мая 2011

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

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

public static string GetPropertyName(this MethodBase methodBase)
{
    return methodBase.Name.Substring(4);
}

Это означает, что ваши наборы свойств устойчивы к изменениям имен и выглядят следующим образом:

private string _name;
public string Name
{
    get { return _name; }
    set 
    {
            name = value;
            RaisePropertyChanged(MethodBase.GetCurrentMethod().GetPropertyName()); 
    }
}

Я написал больше об этом методе расширения здесь , и я опубликовал соответствующий фрагмент кода здесь .

...