Silverlight - передайте между 2 моделями представления в MVVM использующие команды
Я думаю, что объемом является самая большая проблема здесь, как Вы указали.
В, "в то время как" пример, итератор объявляется вне цикла, таким образом, это продолжит существовать после того, как цикл сделан. Это может вызвать проблемы, если этот тот же итератор используется снова в некоторой более поздней точке. Например, можно забыть инициализировать его перед использованием его в другом цикле.
В "для" примера, итератор объявляется в цикле, таким образом, его объем ограничен циклом. При попытке использовать его после цикла, Вы получите ошибку компилятора.
3 ответа
Есть несколько способов сделать это.
Во-первых, вполне уместно иметь ViewModels, состоящие из других ViewModels, если вы согласны с их соединением в этом путь. Когда вы это сделаете, они могут просто разговаривать друг с другом, используя обычные вызовы методов.
Затем вы можете немного разъединить и использовать события. В этом нет ничего плохого. Связь Observer -> Observable все еще существует, но они меньше зависят друг от друга.
Затем вы можете полностью разделить и использовать что-то вроде EventAggregator (у Prism есть хороший, который вы можете использовать). Снимать Опубликовать сообщение. Другой подписывается. Они вообще ничего не знают друг о друге.
Я также использовал для этого команды ... но для связи между ViewModel и ViewModel я нахожу это немного неудобным.
Это кажется идеальной ситуацией для использования EventAggregator, подобного тому, который указан в руководстве / призме составного приложения.
В этой модели вы можете настроить шину сообщений в корне приложения. (или другое место общего пользования).
// в App.xaml.cs
public static IEventAggregator MessageBus = new EventAggregator ();
Затем настраиваем общую библиотеку сообщений
// in Messages.cs
public class SimpleCommand: CompositePresentationEvent<SimpleObject> { }
Где SimpleObject - это класс или переменная, содержащая всю необходимую информацию для обработки этого события.
// in control with button
App.MessageBus.GetEvent<Messages.SimpleCommand>().Publish(SimpleObject);
// anywhere in your app that you "care" about this
App.MessageBus.GetEvent<Messages.SimpleCommand>().Subscribe(ProcessingMethod);
Где ProcessingMethod - это метод, который принимает SimpleObject в качестве параметра.
Затем вы можете отправлять сообщения из любого места и обрабатывать их где угодно - через модели просмотра, элементы управления и т. д. Вы даже можете передавать сообщения MessageBuses между компоненты, если вы динамически загружаете части приложения. Хорошо работает.
You should probably start with most obvious implementation where parent viewmodel simply holds a reference to a child viewmodel, and child viewmodel holds a reference to a parent viewmodel. Then when a command is executed on parent viewmodel it simply sets a value on a child viewmodel to which textbox is bound to.
Adding a layer of abstraction between parent and child (e.g. events) adds a level of complexity and as a result it should be justified. If the value this indirection provides is higher than the cost of increased complexity of the code (e.g. it's now less clear what happens when command on a parent is executed, you will have to solve a problem how child gets subscribed to parent's event without obtaining the actual reference to it and vice-versa, adding additional dependencies between parent a child will require adding additional events, which pollutes the actual logic with all the plumbing, etc.) then certainly events (or something like PropertyObserver) might be a next logic step.