когда надо быстро, я в
app.xaml
добавляю ресурс:
<vm:MainModel x:Key=MainMOdel/>
и в форме DataContext={StaticResource MainModel}

если надо сложнее логику, то в App.xaml можно указать процедуру загрузки и в ней создать\загрузить VM, создать V и связать.
CodeBehind я лично не отделаю от View, но смысл в том, что CB не должен зависеть от VM, то есть взаимодействие только с объектами визуального дерева и не более.

Возникает еще 1 момент, это окна, как открыть новое окно из VM? =)

Shocker.ProRoman Mejtesсоздать\загрузить VM, создать V и связать.то есть уровень бизнес-логики зависит и от V и от VM? А связываешь ты как. Бизнес модель привязывает MyView.DataContext=MyVM?

А с чем взаимодействует бизнес-логика? Откуда забирает и куда докидывает данные, откуда получает события?

Как поступать, если нужно, чтобы события взаимодействовали с ViewModel, если сам CodeBehind не зависит от VM? Транслировать через View, налепливая какие-то дополнительные ICommand?
Передавать события в MVVM невозможно, но совершенно спокойно можно передать делегат или предикат как свойство, через связывание.

Я использую RoutedCommand и ICommand в паре. Для этого я сделал класс слушатель, он следит за автоматизируемым событием CommandExecute и CommandCanExecute и когда оно "всплывает" (так как оно бабл), вызывается связанная с этим маршрутизируемой командой, команда из модели представления (ICommand) .
Всё взаимодействие из направлении из View в ViewModel идет через команды, особенно RoutedCommand вывозят в ContentPresenter'ах, списках и прочих контейрерах + кнопки + элементы меню + Application.commands.

Обычно весь View я делаю в DataTemplate'ах, а ContentControl'ы (такие как формы и userControl'ы) использую очень редко, проще сделать шаблон и отобразить его в Presenter'е для любой модели. По этому CodeBehind у меня весь находится не в прикрепленных к XAMLу файлах с кодом, а отдельно в хелперах, либо я создаю нужный мне контрол с нужным поведением на базе существующих или скомпонованный из существующих примитивов. То есть, в XAML файлах кода в 99% случаев нет вообще, если он нужен он привязывается в дереве там, где необходим через Interactive или AttachedProperty.
Грубо говоря, если мне нужно добавить логику Drag&Drop для панели, я создаю класс DragDropHelper, в нем прикрепляемое свойсто
IsDragDropEnabled и когда его значение меняется на тру, для контрола к котому применяется значение прикрепляются все нужные мне обработчики событий. Получается, что вся логика отвечающая за Drag & Drop у меня в отдельном классе.

Алексей КShocker.ProИзначально одна зависимость уже есть CodeBehind зависит от XAML.Только если XAML содержит именованные элементы.
а что это дает для VM? =) VM ни чего не знает об объектах View их именнованности и в VM не должно быть не 1 ссылки на объекты View модели
2_Shocker.Pro : я тебе накидаю пример проекта и кину сюда чуток по позже, сегодня или завтра. Сегодня я что то приболел слегка, там будет как раз пример, как перехватить событие во View и вызвать соответствующую команду в ViewModel через команды, в CodeBehind или прямо из XAML.

Алексей КRoman Mejtesпропущено...

а что это дает для VM? =) VM ни чего не знает об объектах View их именнованности и в VM не должно быть не 1 ссылки на объекты View моделиНу если XAML не содержит именованных элементов, то code-behind не может иметь ссылок на них - в этом случае code-behind классическая ViewModel.

зы: Экзотические случаи не рассматриваем.
нам не надо знать имя элемента, чтоб обработать его события через Interactive.Behavior или AttachedProperty, нам не надо знать имена чтоб получить RoutedEvent или RoutedCommand.
Единственное, что в XAML надо использовать имена, это связывание между элементами, анимация, триггеры, части шаблона (PartTemplate атрибут)

Алексей КShocker.Proпропущено...
Ну тогда вопрос - стремиться ли выделить VM как отдельный класс, или наоборот - стремиться уминать все в CB?Ну я для себя решил, что по дефолту всё делается в CB, выносится в отдельный класс по необходимости: например, если вдруг потребуется наследование VM - CB этого к сожалению не умеет.
Shocker.Proпропущено...
ну вопрос-то при этом не отпадает - UC сам имеет свою VM и меняется только масштаб вопроса )Внутри каждого UC вопрос может решаться по разному, в зависимости от масштабов и особенностей каждого отдельного подвопроса. :-)

С другой стороны, здесь многое решают личные предпочтения. У меня в последнее время приоритеты в сторону простоты и минимального объёма кода. Если на каждый чих делать присоединяемые свойства, как тому учат современные практики - это никак не попадает под мои критерии абсолютной правильности. :-)
я общался с другим гуру XAML, так сказать со своими учителем, многие его подходы к разным способом реализации функционала и бизнес логики отличаются от моих, как он говорил, если твой подход работает, он удобен для тебя, пользуйся им :) и радуйся жизни.
Можно и MVC шаблон использовать в XAML, этого ни кто не запрещает.
Лично я предпочитаю, когда все XAML файлы являются просто ресурсами которые я потом использую, следовательно CodeBehind я выношу в отдельные классы которые не размазаны по форму или xaml файлу с кодом или разбиты на Partial, плюс когда нужное поведение в отдельном классе, я могу его легко повторно использовать в любой другой части и даже в другой ситуации, если он универсален.

тыц

пример в проекте, в папке View XAML словари с представлением, в MainView пример CommandListener,
в PersonView для кнопки Delete задана маршрутизируемая команда,
в проекте нет Window вообще, запускает приложение через Application.Statup=<handler>,
ActionCommand - это обычный RelayCommand, просто у меня в проектах он малость навороченный, это тут не нужно




<commands:CommandListener.CommandsCollection> - это обычный AttachedProperty, цеплять можно к любому
<commands:CommandsCollection> - Это FreezableCollection, её необходимо создавать самому, так как AttachedProperty нельзя инициализировать сразу,
commands:CommandBind - это freezble объект, у него есть 3 свойства:
RoutedCommand - указывается маршрутизируемая команда, которая будет прослушиваться
Command - команда которая будет вызывать в контексте ViewModel
IsHandled - это свойство по умолчанию равно True, если указать False, то после того как команда обработается, она продолжит всплывать по дереву и если встретит еще 1 CommandListener то будет обработана еще раз. То есть 1 RoutedCommand можно вызвать 2 разные команды в моделях на разных уровнях, выполняться они будут конечно же в том порядке, в каком расположены в дереве снизу вверх (от ветвей к корню).

ах да, как ты и просил, в проекте нет не 1 XAML файла с CodeBehind )

Shocker.Pro,

авторНо вопрос в другом - таким образом ты придаешь поведение некоторому ОДНОМУ элементу, это удобно для стандартных и относительно универсальных поведений. Но я не понял, как ты поступаешь, когда нужно наполнить форму логикой. Скажем, есть пяток-десяток кнопок, которые надо оживить и которые должны в итоге работать в едином контексте (логично бы в контексте VM). Как ты поступаешь?
не понял вопроса, о чем конкретно идет речь?
вся логика модели, должна быть в моделе,а View её только отражать (логику). Если кнопка не должна работать, значит метод OnCanBlaBlaBla должен реализовывать это в модели для данного ICommand.
Что понимается, под словом оживить?

если объект наследует ICommandSource (BaseButton и её наследники или др.), то у него есть свойство Command, можно сразу на него биндить команду, если это позволяет реализация модели, но к примеру если это просто сущность (элемент ListBox) то у него может быть не быть реализован в модели обработчик команды ICommand (ты же не можешь удалить Person из самого Person), тогда я к Command (например кнопки) задают маршрутизируемую команду и обрабатываю её на том уровне, где этот обработчик реализован. Как в примере, у Person нет ни каких команд, команда есть в MainModel, и именно эта команда вызывается при нажатии на урну и удаляет Person из коллекции.
То есть для любой команды пользователя в UI будет реализована соответствующая команда в модели.

Shocker.Pro,

смысл в том, что вся интерактивность должна оставаться в рамках View, то есть, если нам нужно сделать, к примеру, обработку на кнопки KeyDown, то мы просто добавляем AttachedProperty или через Interactive соответствующее поведение.
В результате выполнения этого поведения должна быть вызвана та или иная команда (либо маршрутизируемая, либо обычная, которую мы получим из свойства которое так же приатачим к этому элементу управления).

Передавать события в VM не нужно, в этом нет необходимости, все события View должны обрабатывать на том же уровне.
К примеру, нам надо сделать DragAndDrop, соответственно в представлении (во View) я создаю класс с прикрепляемым свойством
IsCanDrag и привязываю это свойство со значением True к тем объектам, которые я хочу перетаскивать.
В методе OnChanged для данного AttachedProperty, если значение равно True я подписываюсь на 3 события MouseDown, MouseMove, MouseUp, где определяю логику захвата данного элемента управления для перетаскивания и вызывают DragDrop.DoDragDrop().
Для объекта в который идет перетаскивание создает свойство IsCanDrop, где так же добавляются обработчики на события Drop и др.
И свойство DropCommand которое будет связано с командой которая будет вызываться по завершению перетаскивания.
То есть вся логика, отвечающая за перетаскивание объекта лежит на View, а не ViewModel, а все её ньюансы настраиваются через свойства и связывание. В результате я могу применять это поведение практически к любым элементам управления.

Так же, не нужно пренебрегать наследованием. Очень часто я делаю свои контролы с нуля или наследую существующие, в которых определяю всю логику их работы, но как и в первом случаи сам по себе контрол ни чего не знает о ViewModel, у него есть набор DependencyProperty через которые и настраивается его поведение и внешний вид.
То есть сам контрол делает с расчетом на том, что он ни чего не знает о классах модели представления. Сам контрол взаимодействует только со своими свойствами и инициирует выполнение тех или иных команд.
Маршрутизируемые команды можно просто выполнить в код как "Команда.Execute(параметры)" и она тут же всплывает из того контрола в котором её вызывали. Контрол должен быть инкапсулированым и полностью самодостаточным.

Если мне нужна сложная логика размещения\компоновки элементов управления, я создаю свою панель, прибегаю я к этому не часто, так как существующие панели (при их комбинировании) дают довольно широкий спектр возможностей для компоновки

Если прямого взаимодействия между View и ViewModel невозможно избежать, то можно использовать Interface'ы, модель представления реализует заданный интерфейс, эта модель биндится к заданному свойству, элемент управления во View проверяет, полученный объект на и дергает за нужные методы\свойства\события этого интерфейса.
Такой подход реализован в INotifyPropertyChanged, ICollectionView, INotifyCollectionChanged, ICommand и всех это устраивает. Ведь такой подход остается униварсальным.
Вы знаете, что есть контрол для которого в 1 из свойств передается соответствующий интерфейс, вы его реализуете прикрепляете и всё в шоколаде.

когда мне надо быстро, без заморочек с подключением сборки Interactive я использую AttachedProperty, а так как я ленивая скотина, я использую его в большинстве случаев, так как это просто, удобно и главное понятно, я же могу быстро посмотреть что задает это свойство, видно, что оно не "родное". + я могу определить, что данное свойство влияет на пересчет размеров, компоновки и рендеринга.

очень часто приходится сталкиваться с низкой производительностью чисто декларативного подхода, тогда приходится создавать свой собственный контрол, который будет сделан на основе Visual объектов, но тут нужно подходить с умом. Знать когда использовать Visual, когда UIControl'ы, каждый UIControl наследуется от Visual, но поверх там наколбашено очень много всего.
Производительность Visual на много больше, но возможностей у них на много меньше. Мы по сути, можем определить только как выглядит объект, и где он находится, всю логику взаимодействия нужно делать в рамках класса (например) Control.
Visual объект можно поместить в UIElement, но UIElement нельзя поместить в Visual (не считая VisualBrush и BitmapCacheBrush, да и за помещение это назвать сложно). Но можно создать визуальное дерево самих Visual объектов, если в этом есть необходимость.

Shocker.ProРоман, по твоему опыту - есть ли принципиально ситуации, где ViewModel требуется наследовать от DependencyObject (чтобы создавать свойства зависимости) или во всех случаях достаточно INotifyPropertyChanged?
такого не было :) и не будет.
возможно просто этому свойству место во View, в не во ViewModel.

Если свойство контрола (во View), не DP, а обычное, то возникает проблема связывания.
ак как невозможно связать вместе два обычных свойства, тогда, обычно, используют Proxy класс который будет осуществлять это связывание.
Но тут возникает еще несколько проблем:
а) в свойстве контрола, при изменении может не вызывается INotifyPropertyChanged.OnPropertyChanged, следовательно через Proxy всё равно нельзя будет обновить значение во ViewModel, если оно изменится во View
б) такая канитель сильно запутывает код

по этому такими вещами редко страдаю, я даже отказался от SelectedItems свойства (для примеру) у ListBox. Вместо этого, у меня для списков есть обёрточный класс, он сам оповещает меня о том, что выделение изменилось, как только у одного из элементов списка свойства IsSelected изменится, при чем, если оно изменится не у одного, а у нескольких элементов (когда выделение Single, с одного элементы IsSelected становится False, а у другого True), то я всё равно получу один вызов события, а в событие сразу передается список выделенных элементов, через Dispatcher