Нарушение шаблона Model-View-ViewModel DRY?
Кроме того, можно скопировать объект со средства поиска с помощью команды-C, вскочить в Терминал (например, использующий Центр внимания, или QuickSilver) вводят 'CD' и просто вставляют с командой-v
4 ответа
Лично мне не нравится то, что там делает Дино, и я бы не стал подходить к проблеме таким же образом. Я обычно думаю о виртуальной машине как о фильтрованных, сгруппированных и отсортированных коллекциях классов модели. Для меня виртуальная машина - это прямое сопоставление с представлением, поэтому я мог бы создать класс NewOrderViewModel, который имеет несколько видов CollectionView, используемых представлением (возможно, одно резюме для клиентов и другое резюме для продуктов, вероятно, оба отфильтрованы). На мой взгляд, создание совершенно нового класса ВМ для каждого класса в модели нарушает принцип DRY. Я бы предпочел использовать производные или частичные классы для расширения модели там, где это необходимо, добавляя в представление определенные (часто вычисляемые) свойства. IMO .NET RIA Services - отличная реализация объединения данных M и VM с дополнительным бонусом, который можно использовать как на клиенте, так и на сервере. Дино
DRY - это принцип, а не жесткое правило. Вы человек и умеете различать. Например, если бы DRY действительно было жестким правилом, вы бы никогда не присвоили одно и то же значение двум разным переменным. Я полагаю, что в любой нетривиальной программе у вас будет более одной переменной, содержащей значение 0.
Вообще говоря: DRY обычно не применяется к данным. Эти конкретные объекты представления, вероятно, будут только объектами передачи данных без какой-либо примечательной логики. Данные могут дублироваться по разным причинам.
Я думаю, что ответ действительно зависит от того, что, по вашему мнению, должно быть во ViewModel. Для меня ViewModel представляет модель экрана, отображаемого в данный момент.
Так что для чего-то вроде ViewCategoryViewModel у меня нет дублирования полей в категории. Я выставляю объект Category как свойство модели ViewModel (скажем, «SelectedCategory»), любые другие данные, которые необходимо отображать, и команды, которые может принимать экран.
Всегда будет некоторое сходство между моделью предметной области и модель представления, но все сводится к выбору способа создания модели представления.
Это то же самое, что и с объектами передачи данных (DTO).
Домен для этих двух типов объектов различается, поэтому это не нарушение СУХОЙ .
Рассмотрим следующий пример:
class Customer
{
public int Age
}
И корреспондирующая модель представления:
class CustomerViewModel
{
public string Age;
// WPF validation code is going to be a bit more complicated:
public bool IsValid()
{
return string.IsNullOrEmpty(Age) == false;
}
}
Различные домены - разные типы свойств - разные объекты.