MVVM нарушает DRY?

Это интересное замечание ... действительно, часто бывает необходимо изменить ViewModel, чтобы отразить изменения в модели.

Было бы неплохо, если бы это могло быть автоматическим ... фактически Я думаю, что это возможно, если реализовать ICustomTypeDescriptor в ViewModel: GetProperties вернет все свойства модели через отражение. Однако я не уверен, что это будет иметь смысл, потому что модель может вообще не состоять из свойств: это могут быть методы, поля или что-то еще, и не все в модели будет полезно во ViewModel.

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

Возьмите календарь. Вы можете спросить у класса, какое сегодня число, какой месяц, сколько дней в каждом месяце, ... Однако у него нет графического представления. View (CalenderViewMonth или как хотите) печатает на экране один месяц. Он знает календарь и спрашивает его, что писать в разных ячейках.

По сути - у вас может быть что-то не так в вашем моделировании / понимании MVVM (который является современным .NET-вариантом MVC).

Изменить:

Я только что нашел MVVM в Википедии. Модель аналогична модели в MVC. Просмотр аналогичен представлению в MVC - только графическое представление. ViewModel является связующим звеном между общим представлением и специализированной моделью. Какой-то переходник. Нарушения DRY быть не должно.

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

т.е.

public abstract class ViewModelBase<T>
{
    public T Model { get; set; }
}

Если в вашей модели реализован INotifyPropertyChanged, ваше представление получит событие. Это дает вашему представлению доступ ко всем свойствам в вашей модели, что иногда бывает не так.

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

public abstract class SampleViewModel
{
    public int MyProperty
    {
        get { return Model.MyProperty; }
        set
        {
            Model.MyProperty = value;
            OnPropertyChanged("MyProperty");
        }
    }
}

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

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

Другие предоставили хорошие комментарии о ролях компонентов шаблонов MVC / MVVM. Я хотел бы предложить фундаментальное наблюдение, объясняющее повторяемость независимо от того, какой шаблон вы выберете.

Как правило, между уровнем данных, бизнес-уровнем и уровнем пользовательского интерфейса будет какое-то повторение. В конце концов, вы должны показать каждое свойство конечному пользователю (UI), модель его поведение (бизнес-уровень) и сохранить значение (данные слой).

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

При работе над достаточно большими системами (или над небольшими проектами с правильной командой ), Я стараюсь моделировать этот тип информации в UML и использовать генерацию кода (часто в сочетании с частичными классами) для обработки повторяющихся аспектов. В качестве простого примера, свойство Last Name может иметь требование (в моей модели UML), чтобы оно ограничивало данные 50 символами. Я могу сгенерировать код для обеспечения этого ограничения на моем уровне пользовательского интерфейса (например, путем физического ограничения ввода), сгенерировать код на моем бизнес-уровне, чтобы повторно проверить это ограничение («никогда не доверять пользовательскому интерфейсу»), возможно, выбрасывая исключение, если данные слишком длинные, и сгенерировать мой уровень сохраняемости (например, столбец NVARCHAR (50), соответствующий файл сопоставления ORM и т. д.).

Обновление 2012 г.

Аннотации данных Microsoft и их поддержка на уровне пользовательского интерфейса (например, ] ASP.Net MVC ) и на уровне данных ( Entity Framework ) имеет большое значение для реализации многих проблем, для которых я ранее создавал код.

Одна вещь, которую здесь упустили и которую не раскрывает ваш упрощенный пример, - это тот факт, что ваши представления часто объединяют данные, содержащиеся в нескольких Типы доменных моделей. В этом случае ваши ViewModels будут содержать ссылки на ряд моделей предметной области (разных типов), таким образом, агрегируя набор связанных данных, которые конкретное View может захотеть раскрыть.