Каковы за и против различных методов создания представления в WPF?
Я использовал MVVM в течение прошлых двух лет, и он, конечно, развился к лучшему с этого времени. Когда я читал, хотя сотни статей MVVM и stackoverflow вопросов, я заметил, что, кажется, существует все больше статей, которые описывают view/viewmodel отношения и создание как ViewModel сначала или Представление сначала. Эти статьи обычно используют МОК или DI.
Моя любимая техника была использованием datatemplates для создания представлений и структурирования приложения прочь viewmodels, а не представления. Я редко вижу статьи больше, которые используют этот шаблон.
<DataTemplate DataType="{x:Type ViewModels:DummyViewModel}">
<Views:DummyUserControl DataContext="{Binding}"/>
</DataTemplate>
Тестируемость и отделение, кажется, основной фокус этих 'non-datatemplate' V-VM проекты создания/отношений и статьи, и часто они имеют отношение к MEF или ПРИЗМЕ. В конечном счете я хотел бы знать следующее:
- Метод создания представления DataTemplate все еще используется или рекомендован?
- Каковы профессионалы/недостатки представления, сначала разрабатывают?
- Каковы профессионалы/недостатки viewmodel, сначала разрабатывают (с введенным представлением)
Любые хорошие ссылки на статьи, затрагивающие эти темы, ценятся, если они не связанный MEF/PRISM.
2 ответа
1. Используйте технику создания просмотра DataTemplate все еще используемые или рекомендуемые?
Это мой предпочтительный метод работы в MVVM. Мне очень нравится этот подход, по причинам, по которым я указываю ниже. Я использую это во все моего развития.
2. Какие плюсы / минусы просмотра первого дизайна?
Главный про здесь я нашел, заключается в том, что оно немного проще в опыте проектирования. Дизайнер «знает» контекст данных заранее и имеет тенденцию сделать проще проще работы.
Главный контейнер здесь, с моей точки зрения, вы добавляете более жесткую связь между видом и ViewModel. Также сложнее выбрать конкретную модель для передачи.
3. Что представляют собой плюсы / минусы первого дизайна ViewModel (с представлением введены)
Я лично понравился этот подход. Таким образом, «логическая» сторона вашего приложения полностью содержится в вашем слое ViewModel. Используя ContentPresenters, вы можете легко создавать программы ViewModel, определяя «поток» вашего приложения. Представления могут быть очень легко изменены дизайнером.
Здесь, однако, является небольшим снижением энтерибильности времени проектирования, хотя, поскольку представления действительно ничего не знают о VM в Design, вы теряете некоторую обозначение.
Мы столкнулись с тем, что подход DataTemplate имеет некоторые ограничения. На примере шаблон инстанцируется как общий (однокнопочный) экземпляр. В некоторых сценариях это имеет нежелательные побочные эффекты. Именно по этой причине мы используем первую конструкцию ViewModel (с инжекцией вида).
Используемый нами подход описан на странице проекта WPF Application Framework (WAF):
http://waf.codeplex.com/wikipage?title=Model-View-ViewModel%20Pattern&ProjectName=waf