Разделение Master-Detail между двумя моделями представления: куда поместить логику команды отмены?

Главный раздел окна содержит DataGrid. В разделе Details отображается форма, позволяющая редактировать запись, выбранную в настоящий момент в DataGrid мастера. SelectedItem сетки привязан к главной виртуальной машине. Когда это свойство изменяется, главная виртуальная машина создает новую модель EditViewModel, предоставляя ее через свойство. Раздел сведений представления использует это свойство в качестве контекста данных.

При реализации таких команд, как отмена, поместите ли вы их в основную или детальную модель представления?

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

Спасибо,
Бен

Правка: пояснение: под «реализацией команд» я подразумеваю реализацию кода, запрашивающего сервисный уровень для выполнения запрошенного действия.


mvvm .net c# master-detail wpf
person Ben Gribaudo    schedule 13.07.2010    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Я думаю, что ваш второй аргумент намного сильнее первого.

Просто личное мнение, но мне кажется, что удаление - это забота коллекции, а не отдельной записи.

person kiwipom    schedule 13.07.2010

arrow_upward
2
arrow_downward

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

Таким образом, если на данный момент удаление происходит в основном из списка пользовательского интерфейса, то размещение удаления в виртуальной машине коллекции имеет большой смысл.

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

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

person David Hall    schedule 14.07.2010
comment
Хорошая точка зрения. Моя ошибка в описании. Я имел в виду что-то вроде того, где лучше всего поместить логику команды, которая вызывает удаление, на сервисном уровне? - person Ben Gribaudo; 14.07.2010

arrow_upward
0
arrow_downward

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

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

person Jose    schedule 14.07.2010