Думаю, всем известно, что MemberwiseClone копирует ссылки, а не объекты, на которые они ссылаются. Поэтому если требуется "глубокое" копирование при реализации Clone() следует инициализировать соответствующие объекты.
Вот только при написании Clone() для ViewModel-ей легко забыть, что свойства типа ICommand ссылаются на делегаты и их тоже нужно инициализировать в Clone(). Иначе по нажатию кнопки обработчик будет вызываться в оригинальном объекте, а не в копии. И есть вероятность, что вы просидите час в отладчике, как и я, выискивая ошибки binding-а
19.07.11 22:19: Перенесено модератором из '.NET' — TK
Never argue with a woman who reads. It's likely she can also think. (c)
HL>Свойства типа ICommand ссылаются на реализации ICommand, которые не обазаны быть вариациями на тему DelegateCommand/RelayCommand.
Да, но очень часто являются
HL>А зачем вам понадобилось клонировать view model'и?
Ну, в данном случае был список, каждый элемент которого — ViewModel, внутри которой объект предметной области. Источником данных для списка является репозиторий, поддерживающий обновления с удаленного сервиса. По двойному клику открывалось диалоговое окно со свойствами Selected Item этого списка. В окне пользователь может изменить эту VM, после чего уходит команда на сервис и окно сразу же закрывается. Результатом работы сервиса является обновленный объект, на основе которого строится данная VM и который будет получен клиентом асинхронно через репозиторий. Собственно клонирование было нужно для того, чтобы объект в списке не менялся при изменении данной VM в диалоговом окне.
Never argue with a woman who reads. It's likely she can also think. (c)
Здравствуйте, Agent Smith, Вы писали:
AS>Собственно клонирование было нужно для того, чтобы объект в списке не менялся при изменении данной VM в диалоговом окне.
А как клонирование view model спасло от создания объекта в списке?
Клон — это же все равно новый объект, просто у него значения свойств схожи с оригиналом.
По-моему, логичнее, при поступлении от сервиса объекта предметной области, найти в репозитории его локальную копию, и обновить ее свойства. Как следствие, обновится его модель представления в списке. Это будет как минимум проще, чем клонирование.
Здравствуйте, Agent Smith, Вы писали:
HL>>Свойства типа ICommand ссылаются на реализации ICommand, которые не обазаны быть вариациями на тему DelegateCommand/RelayCommand.
AS>Да, но очень часто являются
HL>>А зачем вам понадобилось клонировать view model'и?
AS>Ну, в данном случае был список, каждый элемент которого — ViewModel, внутри которой объект предметной области. Источником данных для списка является репозиторий, поддерживающий обновления с удаленного сервиса. По двойному клику открывалось диалоговое окно со свойствами Selected Item этого списка. В окне пользователь может изменить эту VM, после чего уходит команда на сервис и окно сразу же закрывается. Результатом работы сервиса является обновленный объект, на основе которого строится данная VM и который будет получен клиентом асинхронно через репозиторий. Собственно клонирование было нужно для того, чтобы объект в списке не менялся при изменении данной VM в диалоговом окне.
Лучше делайте копии объектов.
