когда надо быстро, я в
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.
Что понимается, под словом оживить?