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

Question

Мастер секция окна содержит DataGrid. В разделе «Сведения» отображается форма, позволяющая редактировать запись, выбранную в данный момент в главной таблице данных. Выбранный элемент сетки привязан к мастеру vm. Когда это свойство изменяется, мастер vm создает новый EditViewModel, предоставляя его через свойство. Раздел сведений представления использует это свойство в качестве своего DataContext.

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

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

Спасибо,
Бен

Редактировать : Уточнение - под «реализацией команд» я имею в виду реализацию кода, который просит уровень обслуживания выполнить запрошенное действие.

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

Каждая запись знает только о себе.Он даже не должен понимать, что это часть коллекции, это сущность сама по себе.Основная ВМ имеет коллекцию записей, поэтому она должна отвечать за изменения.

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