WPF/SL MVVM framework - .NET GUI

Здравствуйте, henson, Вы писали:

H>Интересно замечание. Я только не понял что значит выставлять модель UI через публичное API. Если вы про ViewModel класс, то он и не предназначен для выставления наружу и вообще служит только как Back End для конкретного View или набора однотипных Views.

Нет, это я про использование mv* для автоматизации UI. Очевидно, в этом случае mv-фреймворк будет бесполезен.
— Во-первых, мы привяжем к нему внешнее API, и следовательно, не сможем поменять UI-фреймворк без того, чтобы не переписывать все addin-ы. Fail.
— Во-вторых, для более-менее серьёзного софта нам один фиг придётся давать доступ непосредственно к visual tree и тут mv-фреймворк в лучшем случае нам ничем не поможет, а в худшем — будет только мешать. Тем более что в WPF для контролов _уже_ существует полноценный mv-подход.

Ещё один аргумент "за" mv* в десктоп-софте — необходимость модульного тестирования UI-слоя, но это _очень_ спорный вопрос.
— Во-первых, куда проще и надёжней использовать windows automation — тем более что для этого есть десятки неплохих инструментов, автоматически записывающих скрипт по действиям пользователя.
— Во-вторых, кто будет гарантировать, что "правильный" результат в модели означает правильный результат на экране?

Сразу оговорюсь, что MV — вовсе необязательно зло. Как идеальный пример правильной реализации — ASP.Net MVC.

Вся философия VM-фреймворков крутится (и всегда крутилась) вокруг отделения UI-слоя от остальной части приложения. Вся тема зародилась в 80е — как один из (подчёркиваю, один из) подходов к проектированию UI-фреймворка для smalltalk. Потом MV (опять-таки, в качестве примера а не идеала проектирования) упомянул Фаулер, потом хайп подхватили яваисты, затем он прижился в вебе и, наконец, пришёл в WPF.

Внезапно (мне честно лень искать первоисточник этой дури) MV* начал применяться при проектировании пользовательского кода путём слепого заимствования практик, предназначенных для решения задач, характерных для UI фреймворка — разделения кода на "рисующую" часть, на поведение контрола и на всё остальное — т.е на тот самый пользовательский код

Самое печальное, что весь этот хайп самоподдерживается — про mv пишут, значит он моден. Я разработал фреймворк под модную тему — как MV может быть отстоем? По теме есть конференции и даже доклады на mix — как же нам его не изучать? Люди хотят изучить MVVM — почему бы не написать книжку...

И наконец мы пишем фреймворки, которые облегчают написание бизнес-логики в стиле, принятом для написания UI-фреймворков и обвиняем собсно UI-фреймворки что они плохо заточены под паттерны 30-летней давности.

И никто и никогда не потратит своё время, чтобы прочитать собсно основоположника MVVM и осознать, что MVVM — очень специфическая и узконишевая штука, которая в 90% приведёт к тупому переизобретению того, что уже есть в WPF

В результате происходит классическая утечка абстракций — в контроллере или в модели появляются свойства IsButtonPressed, Panel1Visible etc.

Пардон, но какая бизнес-логике разница: подтвердил пользователь заказ нажатием кнопки или галочкой в тексбоксе? Если всё, что требуется — это сам факт подтверждения, т.е. свойство IsSomethingConfirmed в модели (ну, или метод Accept() в контроллере — не суть важно), зачем вносить в модель/логику какие-либо знания об ui-слое и об его поведении?

P.S. То же самое, но другими словами. Грабли непосредственно MVVM.

Здравствуйте, Sinix, Вы писали:

Спасибо за интересный комментарий. Собственный опыт использования SCSF говорит о том, что либо мы не умеем его правильно готовить, либо он плохо подходит для наших задач. В действительности, какую-то пользу приносит только ObjectBuilder, все остальное, что идет в нагрузку, только усложняет нам жизнь. А если подумать, что ObjectBuilder как IoC движок очень убогий, то смысла в CAB для наших задач я особенно не вижу. Возьмем рассмотрим Prism:

С MSDN — http://msdn.microsoft.com/en-us/library/ff648465.aspx

Architectural Goals
The guidance is designed to help architects and developers achieve the following objectives:

Create an application from modules that can be built, assembled, and, optionally, deployed by independent teams using WPF or Silverlight.

Minimize cross-team dependencies and allow teams to specialize in different areas, such as user interface (UI) design, business logic implementation, and infrastructure code development.

Use an architecture that promotes reusability across independent teams.

Increase the quality of applications by abstracting common services that are available to all the teams.

Incrementally integrate new capabilities.

Давайте пройдем по пунктам:
Create an application from modules that can be built, assembled, and, optionally, deployed by independent teams using WPF or Silverlight.

Use an architecture that promotes reusability across independent teams.
Опять таки, если команда одна, то reusability продвигается более простыми способами.

Increase the quality of applications by abstracting common services that are available to all the teams.
Те common services которые нам нужны, проще взять отдельно, не надо тащить с собой весь фреймворк.

Incrementally integrate new capabilities.
Ну это вообще вопрос правильной архитектуры и Prism здесь если и решит, то только часть проблем. Т.к. прежде всего нужно найти ответ на вопрос "А как скорее всего будет меняться/развиваться наша система?". И я уверен, что в подавляющем большинстве случаев это самое развитие идет не через добавление новых модулей, а через развитие существующих.

А теперь, внимание, вопрос, зачем мне Prism?

Здравствуйте, MaximVK, Вы писали:

MVK>Также очень интересно узнать, кто какой фреймворк предпочитает и почему.

Для начала лучше определиться, что ждёшь от подобного фреймворка:

гибкой архитектуры UI
решения рутинных задач в связке MVVM+WPF/SL
быстренько наклепать UI, не вдаваясь в подробности, но чтобы типа правильно было

В порядке уменьшения целесообразности использования стороннего фреймворка:

Для (3) бери любой, все равно рано или поздно упрешься либо в какие-то рамки, либо в отсутствие чего-либо, либо в сложности расширения

Для (2) ради пары-тройки удобных helper-ов тащить какие-то библиотеки, которые иногда ещё навязывают свою архитектуру не очень удобно. После определённого опыта с WPF/SL такие штуки пишутся самостоятельно, причём иногда более удобные, т.к. учитывают специфику проекта(-ов), где задача более узкая, чем у фреймворка. В крайнем случае можно выдрать точечно откуда-нибудь.

Для (1) сначала отсеять псевдо-фреймворки, которые никакой архитектуры не предоставляют (всякие BaseViewModel с OnPropertyChanged), а из оставшихся взять только идеи и адаптировать их для своего проекта. Иначе, если тут упрешься во что-то, то придется городить огород всяких pure fabrication (читай ненужных классов) для обхода архитектурных проблем путем добавления лишних абстракций, что приведёт к overdesign-у. Видел подобные решения на базе Prism => ещё хуже, чем SCSF.

Лично мне нравится идея абстрагироваться от (*) в связке MV(*) с помощью Screen-ов, поэтому я взял за основу их реализацию в Caliburn Micro и объединил с реализацией регионов из Prism (Region по сути ScreenConductor). На базе этого UI собирается и разбирается как трансформер в любых комбинациях (естественно пронизанный IoC, Events, Binder и др).

Здравствуйте, MaximVK, Вы писали:

MVK>Здравствуйте, Sinix, Вы писали:

MVK>Давайте пройдем по пунктам:
MVK>Create an application from modules that can be built, assembled, and, optionally, deployed by independent teams using WPF or Silverlight.
MVK>

Minimize cross-team dependencies and allow teams to specialize in different areas, such as user interface (UI) design, business logic implementation, and infrastructure code development.
MVK>Т.е. если команда одна, то необходимость в организации cross-team collaboration отпадает сама собой.

Сегодня одна, завтра две или больше. У вас менеджмент не любит преподносить сюрпризы в виде аутсорса кусков в индию?

MVK>

Use an architecture that promotes reusability across independent teams.
MVK>Опять таки, если команда одна, то reusability продвигается более простыми способами.

Масштабируемость значит страдает если количество команд влияет на подходы. Может быть конечно у вас идеальная документация на все компоненты системы и тогда это не проблема.
Но чаще всего самописные архитектуры страдают от невразумительного документирования и реализации. Я видел двух гениев которые пытались выдумать свой аналог WPF во времена .NET 2.0
Оно как-то работало, но Microsoft сдалала это намного лучше.

MVK>

Increase the quality of applications by abstracting common services that are available to all the teams.
MVK>Те common services которые нам нужны, проще взять отдельно, не надо тащить с собой весь фреймворк.

Так все фреймворки используются: берешь что надо сейчас, остальное может быть понадобится потом. Пример Enterprise Library.

MVK>

Incrementally integrate new capabilities.
MVK>Ну это вообще вопрос правильной архитектуры и Prism здесь если и решит, то только часть проблем. Т.к. прежде всего нужно найти ответ на вопрос "А как скорее всего будет меняться/развиваться наша система?". И я уверен, что в подавляющем большинстве случаев это самое развитие идет не через добавление новых модулей, а через развитие существующих.

Prism это больше чем концепция модулей. Может вам он и незачем, а другим вполне подойдет.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, henson, Вы писали:

S>Вся философия VM-фреймворков крутится (и всегда крутилась) вокруг отделения UI-слоя от остальной части приложения. Вся тема зародилась в 80е — как один из (подчёркиваю, один из) подходов к проектированию UI-фреймворка для smalltalk. Потом MV (опять-таки, в качестве примера а не идеала проектирования) упомянул Фаулер, потом хайп подхватили яваисты, затем он прижился в вебе и, наконец, пришёл в WPF.

S>Внезапно (мне честно лень искать первоисточник этой дури) MV* начал применяться при проектировании пользовательского кода путём слепого заимствования практик, предназначенных для решения задач, характерных для UI фреймворка — разделения кода на "рисующую" часть, на поведение контрола и на всё остальное — т.е на тот самый пользовательский код

S>Самое печальное, что весь этот хайп самоподдерживается — про mv пишут, значит он моден. Я разработал фреймворк под модную тему — как MV может быть отстоем? По теме есть конференции и даже доклады на mix — как же нам его не изучать? Люди хотят изучить MVVM — почему бы не написать книжку...

S>И наконец мы пишем фреймворки, которые облегчают написание бизнес-логики в стиле, принятом для написания UI-фреймворков и обвиняем собсно UI-фреймворки что они плохо заточены под паттерны 30-летней давности.

Стиль "принятый для написания UI-фреймворков" является разделением ответственности. Мне сложно представить ситуацию, где этот подход себя не оправдает.

S>И никто и никогда не потратит своё время, чтобы прочитать собсно основоположника MVVM и осознать, что MVVM — очень специфическая и узконишевая штука, которая в 90% приведёт к тупому переизобретению того, что уже есть в WPF

Что такого переизобретает MVVM-подход, что уже есть в WPF?

S>В результате происходит классическая утечка абстракций — в контроллере или в модели появляются свойства IsButtonPressed, Panel1Visible etc.

Не понял, откуда это взялось? Такое может встретиться только в хрестоматийном code-behind.

S>Пардон, но какая бизнес-логике разница: подтвердил пользователь заказ нажатием кнопки или галочкой в тексбоксе? Если всё, что требуется — это сам факт подтверждения, т.е. свойство IsSomethingConfirmed в модели (ну, или метод Accept() в контроллере — не суть важно), зачем вносить в модель/логику какие-либо знания об ui-слое и об его поведении?

Это и есть подход MVVM — сделать хранение состояния UI независимым от этого самого UI, разделить ответственность. Механизм биндинга как раз помогает этого достигнуть. Правильно приготовленное MVVM-приложение способно работать вообще без UI.

P.S.: вообще у вас довольно сумбурный стиль изложения и точно понять что вы имеете в виду сложно.

Здравствуйте, Vladek, Вы писали:

V>Стиль "принятый для написания UI-фреймворков" является разделением ответственности. Мне сложно представить ситуацию, где этот подход себя не оправдает.

Проблема не в SoC, а в том, что сам MV подход очень отвратно ложится на фреймворки, не заточенные под него. На уровне контролов в WPF уже есть своя модель разнесения функционала — зачем плодить лишние сущности? На уровне приложения оно тоже не годится из-за попыток натянуть фреймворк на то, что фреймворка не требует.

V>Что такого переизобретает MVVM-подход, что уже есть в WPF?
Можно глянуть тут. Основные проблемы
— необходимость ручного написания множества ViewModel-прокладок там, где за глаза хватает биндингов/триггеров.
— пассивный ui и попытка управлять им через бизнес-логику.

S>>В результате происходит классическая утечка абстракций — в контроллере или в модели появляются свойства IsButtonPressed, Panel1Visible etc.
V>Не понял, откуда это взялось? Такое может встретиться только в хрестоматийном code-behind.

Да нет, первые же примеры в гугле.
Джо Госсман. Автор идеи как бы, так что все сомнения в квалификации отпадают. WPF-классы в ViewModel — мы уже привязали поведение приложения к UI-фреймворку.
MSDN. То же + в ViewModel смешан DAL, логика и структура данных приложения.
Товарища ранее не встречал. Те же самые проблемы.

Все 3 примера абсолютно нежизнеспособны в реальном приложении. Возможно, все вышеперечисленные заблуждаются — покажите как с вашей точки зрения выглядит правильный подход.

V>Это и есть подход MVVM — сделать хранение состояния UI независимым от этого самого UI, разделить ответственность. Механизм биндинга как раз помогает этого достигнуть. Правильно приготовленное MVVM-приложение способно работать вообще без UI.

Так эта задача решается средствами почти любого UI-фреймворка без привлечения mvvm. Но MVVM работает только с UI-слоем, забивая на всё остальное. В результате в Model в куче примеров валяются только POCO-классы без ассоциаций и без валидации модели. А собсно всё прилождение перемешано и раскидано по отдельным ViewModel.

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Vladek, Вы писали:

V>>Стиль "принятый для написания UI-фреймворков" является разделением ответственности. Мне сложно представить ситуацию, где этот подход себя не оправдает.

S>Проблема не в SoC, а в том, что сам MV подход очень отвратно ложится на фреймворки, не заточенные под него. На уровне контролов в WPF уже есть своя модель разнесения функционала — зачем плодить лишние сущности? На уровне приложения оно тоже не годится из-за попыток натянуть фреймворк на то, что фреймворка не требует.

MVVM как раз позволяет делать слой данных и бизнес-логики совершенно независимыми от WPF! И ViewModel — вещь необходимая, ибо как раз они и склеивают независимые части в единое приложение, вставая между Model и View.

V>>Что такого переизобретает MVVM-подход, что уже есть в WPF?
S>Можно глянуть тут. Основные проблемы
S>- необходимость ручного написания множества ViewModel-прокладок там, где за глаза хватает биндингов/триггеров.
S>- пассивный ui и попытка управлять им через бизнес-логику.

Джон Госсман в приведённой цитате пишет ровно об обратном. То есть, объясняет зачем модели вида нужны вообще — а нужны они там, где уже не обойтись биндингами напрямую к данным и где нежелательно работать с UI в слое бизнес-логики.

S>>>В результате происходит классическая утечка абстракций — в контроллере или в модели появляются свойства IsButtonPressed, Panel1Visible etc.
V>>Не понял, откуда это взялось? Такое может встретиться только в хрестоматийном code-behind.

S>Да нет, первые же примеры в гугле.
S>Джо Госсман. Автор идеи как бы, так что все сомнения в квалификации отпадают. WPF-классы в ViewModel — мы уже привязали поведение приложения к UI-фреймворку.

ICommand и ICollectionView? Эти абстракции необходимы для работы биндингов и как раз обеспечивают работу MVVM-подхода! Они нас никоим образом не делают зависимыми от слоя View. Никто в модели вида UI-элементы не тащит, в 100% случаев затруднения разрешаются с помощью конвертеров и вложенных свойств (attached properties). Это пример наоборот опровергает ваши слова.

S>MSDN. То же + в ViewModel смешан DAL, логика и структура данных приложения.

А чего вы хотите от примера в три строки? Трёхзвенного приложения с полноценной базой данных? ViewModel и должен зависеть от DAL и бизнес-логики, это же контролёр, мясо приложения. Если надо, другие слои скрываются за интерфейсами и подгружаются через внедрение зависимостей (dependency injection). Опять же пример демонстрирует правильный подход.

S>Товарища ранее не встречал. Те же самые проблемы.

Ткните носом в его проблемы. Серьёзно, где там проблемы и изъяны в архитектуре?

S>Все 3 примера абсолютно нежизнеспособны в реальном приложении. Возможно, все вышеперечисленные заблуждаются — покажите как с вашей точки зрения выглядит правильный подход.

Все три примера как раз демонстрируют правильный подход.

V>>Это и есть подход MVVM — сделать хранение состояния UI независимым от этого самого UI, разделить ответственность. Механизм биндинга как раз помогает этого достигнуть. Правильно приготовленное MVVM-приложение способно работать вообще без UI.

S>Так эта задача решается средствами почти любого UI-фреймворка без привлечения mvvm. Но MVVM работает только с UI-слоем, забивая на всё остальное. В результате в Model в куче примеров валяются только POCO-классы без ассоциаций и без валидации модели. А собсно всё прилождение перемешано и раскидано по отдельным ViewModel.

При любом подходе возможны злоупотребления, никто не спорит, но MVVM вовсе не заставляет устраивать из моделей вида свалку — тут здравый смысл и рефакторинг программисту в помощь.

Здравствуйте, Vladek, Вы писали:

V>MVVM как раз позволяет делать слой данных и бизнес-логики совершенно независимыми от WPF! И ViewModel — вещь необходимая, ибо как раз они и склеивают независимые части в единое приложение, вставая между Model и View.

Ещё одна цитата.

My team has been using the pattern feverishly for a couple of years, and we still don't have a clean definition of the term ViewModel. Model is well understood. View is well understood, if slightly stricter than the MVC definition. But what is this ViewModel thing? Fine...my team uses this word to mean what we want it to mean. But that makes it much harder to introduce and can lead to all sorts of confusion.

One problem is ViewModel actually combines several separate, orthogonal concepts: view state, value conversion, commands for performing operations on the model.

Вот основной косяк у Госсмана: в попытках разделить xaml, данные и всё остальное, он сваливает всё остальное в одну кучу. В результате ViewModel (которая — в теории — всего лишь адаптер для привязки UI к логике и данным) служит контейнером для конвертеров/логики/DAL/схемы данных. Последнее меня особенно поражает, т.к. ассоциации — это, очевидно, ответственность модели.

Если вы считаете это правильной архитектурой, можно просто признать кардинальное расхождение в взглядах и закругляться.

Если нет — продолжим:

V>Джон Госсман в приведённой цитате пишет ровно об обратном. То есть, объясняет зачем модели вида нужны вообще — а нужны они там, где уже не обойтись биндингами напрямую к данным и где нежелательно работать с UI в слое бизнес-логики.

Ок. А где тогда в MVVM живёт та самая бизнес-логика? У Госсмана её нет вообще (та же ссылка, что и в цитате выше):

The role of the Controller is to map user input (keystrokes, mouse actions) to the View and/or Model. ... This then is my reply to that criticism: Controller is still there, it is just implemented by the system and is of little practical interest in the pattern.

V>ICommand и ICollectionView? Эти абстракции необходимы для работы биндингов и как раз обеспечивают работу MVVM-подхода!

А зачем вводить абстракции, которые нужны только для работы прослойки и которые вполне реазизуются в codebehind — без какой-либо формализации? В этом, повторюсь все грабли — если мы делаем прослойку только для UI — она не нужна, т.к. ничем не выигрывает у кода в MyUserControl.xaml.cs. Если мы делаем прослойку для внешнего управления — автоматизации, public api, интерфейс между модулями etc — что в этой прослойке делают ui-specific классы?

Самое поразительное (только что наткнулся), что до Госсмана дошло (точнее, ему мягко намекнули), что в WPF _уже_ есть способ разделения ui|поведения|данных, только ч/з 4 месяца после представления MVVM. Пруф.

V>А чего вы хотите от примера в три строки? Трёхзвенного приложения с полноценной базой данных? ViewModel и должен зависеть от DAL и бизнес-логики, это же контролёр, мясо приложения.
А можно узнать, зачем в контроллер тащится _всё_? Даже value converters, фильтрация и сортировка, команды, структура данных и валидация (см Figure 11)?

Почитайте внимательно статью Джо Смита по последней ссылки. Там весьма занятные примеры применения MVVM — например, используются метамодели для описания структуры UI в терминах MVVM и VM работает эдаким service provider для UI. По сути MVVM в этой статье используется для создания подробнейшей модели UI-слоя приложения — вплоть до создания новых моделей для создания нового customer-а. Весьма красиво, не спорю, но насквозь непрактично из-за значительного усложнения дизайна без особых преимуществ. В этом весь MVVM

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Vladek, Вы писали:

V>>MVVM как раз позволяет делать слой данных и бизнес-логики совершенно независимыми от WPF! И ViewModel — вещь необходимая, ибо как раз они и склеивают независимые части в единое приложение, вставая между Model и View.

S>Ещё одна цитата.
S>

S>My team has been using the pattern feverishly for a couple of years, and we still don't have a clean definition of the term ViewModel. Model is well understood. View is well understood, if slightly stricter than the MVC definition. But what is this ViewModel thing? Fine...my team uses this word to mean what we want it to mean. But that makes it much harder to introduce and can lead to all sorts of confusion.

S>One problem is ViewModel actually combines several separate, orthogonal concepts: view state, value conversion, commands for performing operations on the model.

S>Вот основной косяк у Госсмана: в попытках разделить xaml, данные и всё остальное, он сваливает всё остальное в одну кучу. В результате ViewModel (которая — в теории — всего лишь адаптер для привязки UI к логике и данным) служит контейнером для конвертеров/логики/DAL/схемы данных. Последнее меня особенно поражает, т.к. ассоциации — это, очевидно, ответственность модели.

В цитате выше Госсман всего лишь сетует на трудность представления концепции моделей вида широкой публике. Вы вообще читаете собственные ссылки? Или у вас с английским туговато? Сразу же после этой цитаты Госсман объясняет зачем они свалили всё перечисленное в одну кучу — в других слоях всё это просто лишнее, поэтому они и вывели нового зверя — модели вида. И модель вида вовсе не контейнер, а скорее дирижёр, управляющий оркестром абстракций, присутствующих в других слоях, и позволяющий этим абстракциям не зависеть друг от друга. Дирижёр должен быть в контакте с каждым музыкантом из оркестра, верно? То же самое верно и в отношении моделей вида, в них как раз и реализуется взаимодействие остальных слоёв приложения.

S>Если вы считаете это правильной архитектурой, можно просто признать кардинальное расхождение в взглядах и закругляться.

Не существует правильных архитектур, есть уместные архитектуры. И в мире WPF, MVVM — архитектура уместная, позволяющая соблюдать разделение ответственности.

S>Если нет — продолжим:

S>

V>>Джон Госсман в приведённой цитате пишет ровно об обратном. То есть, объясняет зачем модели вида нужны вообще — а нужны они там, где уже не обойтись биндингами напрямую к данным и где нежелательно работать с UI в слое бизнес-логики.

S>Ок. А где тогда в MVVM живёт та самая бизнес-логика? У Госсмана её нет вообще (та же ссылка, что и в цитате выше):
S>

S>The role of the Controller is to map user input (keystrokes, mouse actions) to the View and/or Model. ... This then is my reply to that criticism: Controller is still there, it is just implemented by the system and is of little practical interest in the pattern.

Controller — это не бизнес-логика, в классическом MVC он ответственен за изменение данных как со стороны View, так и со стороны Model. В WPF, как это и было замечено Госсманом, эту функцию выполняет механизм биндингов, поддержка интерфейса INotifyPropertyChanged, ну и зависимые свойства. Модель вида упрощает использование этих механизмов. Бизнес-логика реализуется отдельно от модели вида, хотя в простейших случаях может быть и встроена в саму модель вида.

V>>ICommand и ICollectionView? Эти абстракции необходимы для работы биндингов и как раз обеспечивают работу MVVM-подхода!

S>А зачем вводить абстракции, которые нужны только для работы прослойки и которые вполне реазизуются в codebehind — без какой-либо формализации? В этом, повторюсь все грабли — если мы делаем прослойку только для UI — она не нужна, т.к. ничем не выигрывает у кода в MyUserControl.xaml.cs.

Эти абстракции необходимы для того, чтобы быть независимым от UI-слоя. Независимость нужна для того, чтобы разрабатывать и/или менять части приложения параллельно без ущерба работоспособности приложения. В MVVM-приложении мы можем делать два совершенно разных UI-слоя и менять между их собой. Если бы у нас был в каждом из них code-behind, то это было бы тупым дублированием функциональности в приложении, ведущем к расхождениям и ошибкам.

S>Если мы делаем прослойку для внешнего управления — автоматизации, public api, интерфейс между модулями etc — что в этой прослойке делают ui-specific классы?

WPF поддерживает автоматизацию из коробки на уровне контролов, более того можно легко в MVVM-приложение добавить поддержку сценариев — они просто заменят моделям вида UI-слой, ибо модели вида от него зависят лишь интерфейсами, а вовсе не UI-specific классами! Так же и со всем остальным, модель вида не имеет представления о конкретном UI, в котором она используется — это UI использует её, в чём не в последнюю очередь ему помогаю перечисленные интерфейсы из WPF.

S>Самое поразительное (только что наткнулся), что до Госсмана дошло (точнее, ему мягко намекнули), что в WPF _уже_ есть способ разделения ui|поведения|данных, только ч/з 4 месяца после представления MVVM. Пруф.

Вы не устаёте приводить ссылки, которые лишь подтверждают мои слова. В посте Госсман рассказывает о коллеге, до которого наконец-то дошёл смысл подхода MVVM и он заметил, что WPF построена на тех же самых принципах, которые и обеспечивают ей добрую часть её преимуществ — функциональная часть контролов независима от их визуального представления, что легко позволяет нам менять внешний вид контролов.

V>>А чего вы хотите от примера в три строки? Трёхзвенного приложения с полноценной базой данных? ViewModel и должен зависеть от DAL и бизнес-логики, это же контролёр, мясо приложения.
S>А можно узнать, зачем в контроллер тащится _всё_? Даже value converters, фильтрация и сортировка, команды, структура данных и валидация (см Figure 11)?

Это и есть главные составные части моделей вида! Они для того и нужны, чтобы преобразовывать данные, подготавливая их для отображения пользователю, применять бизнес-логику к данным в ответ на вызов команд пользователем, проверять целостность данных при их изменении пользователем. Всё это реализуется с помощью вышеперечисленных средств из арсенала WPF.

S>Почитайте внимательно статью Джо Смита по последней ссылки. Там весьма занятные примеры применения MVVM — например, используются метамодели для описания структуры UI в терминах MVVM и VM работает эдаким service provider для UI. По сути MVVM в этой статье используется для создания подробнейшей модели UI-слоя приложения — вплоть до создания новых моделей для создания нового customer-а. Весьма красиво, не спорю, но насквозь непрактично из-за значительного усложнения дизайна без особых преимуществ. В этом весь MVVM

Спасибо, я читал. Прочитайте сами внимательно эту статью, только на русском языке.

Здравствуйте, Vladek, Вы писали:

V>[наезды поскипал]
Предлагаю закругляться, т.к. ничего кроме хождения по кругу не выйдет. Спасибо и

Здравствуйте, henson, Вы писали:

Резюмируя, ты предлагаешь использовать Prism про запас, авось потом пригодиться. Это сильно похоже на premature optimization, что не есть хорошо.

H>Масштабируемость значит страдает если количество команд влияет на подходы.
Количество разработчиков всегда влияет на подходы. Возьми крайний случай — один программист, и другой крайний случай — 1000 человек. Команда из десяти человек, конечно, может использовать подходы, которые применяются при разрабоке проектов в 100-200 человек, только это будет крайне неэффективно.

H>Prism это больше чем концепция модулей. Может вам он и незачем, а другим вполне подойдет.
Хорошо, а что еще? Какие проблемы решает Prism? Что хорошего он принесет, а что плохого?

Здравствуйте, FlevelEx, Вы писали:

FE>Для начала лучше определиться, что ждёшь от подобного фреймворка:

FE>

FE>

гибкой архитектуры UI
FE>

решения рутинных задач в связке MVVM+WPF/SL
FE>

быстренько наклепать UI, не вдаваясь в подробности, но чтобы типа правильно было
FE>

FE>Лично мне нравится идея абстрагироваться от (*) в связке MV(*) с помощью Screen-ов, поэтому я взял за основу их реализацию в Caliburn Micro и объединил с реализацией регионов из Prism (Region по сути ScreenConductor). На базе этого UI собирается и разбирается как трансформер в любых комбинациях (естественно пронизанный IoC, Events, Binder и др).

Спасибо за интересный ответ. Я жду второго пункта: "решения рутинных задач в связке MVVM+WPF/SL".

А чем Region из Prism-a лучше, чем ScreenConductor из Calibrum?

Вот, кстати, пример использования Region-ов в Prism, а именно, активация View через Injection.

   1: string viewName = employeeId.ToString(CultureInfo.InvariantCulture);
   2: IRegion detailsRegion = regionManager.Regions["DetailsRegion"];
   3: object view = detailsRegion.GetView(viewName);
   4:  
   5: if(view == null)
   6: {
   7:     view = Container.Resolve<IEmployeeView>();
   8:     detailsRegion.Add(view, viewName);
   9: }
  10:  
  11: detailsRegion.Activate(view);

Насколько я понимаю, IoC контейнер может быть любой? Если да, то это хорошо.

Кстати, небольшое замечание по коду выше:
Не совсем понятно, кто и управляет жизенным циклом view в этом примере кода. Вроде как содается по новому view на каждого employee. Что делать, если у меня будут открыты сотни EmployeeView форм в течении рабочего дня и мне удобнее иметь одну форму, у которой я буду менять привязку к модели (a la Flyweight)? Где Prism предлагает мне разместить эту логику?

Здравствуйте, Sinix, Вы писали:

S>На уровне контролов в WPF уже есть своя модель разнесения функционала — зачем плодить лишние сущности?
Тоже не раз задумывался над этим. Класс контрола по сути и есть модель. Однако, эта модель не позволяет:

использовать ее с несколькими контролами одновременно.
жестко привязывает нас к WPF-ному дереву наследования.

А так, бенефитов прилично. Хотя-бы то, что привязка к свойствам зависимостей работает быстрее, чем к INotifyPropertyChanged.

Здравствуйте, MxMsk, Вы писали:

MM>Тоже не раз задумывался над этим. Класс контрола по сути и есть модель.
Охх блин! Вот за это я и не люблю MV: все понимают под моделью/view/прочим что-то своё и очень легко скатиться к разборкам в духе "кто знает больше баззвордов". Это просто замечание в сторону, прекрасно понял, что имелось в виду

MM>Однако, эта модель не позволяет:
MM>использовать ее с несколькими контролами одновременно.
Ок, а зачем? Можно примеры, когда недостаточно создания своего контрола/юзер контрола? Реально интересно, обещаю не спорить и не холиварить

MM>

жестко привязывает нас к WPF-ному дереву наследования.
А как иначе? Если не смешивать поведение приложения и поведение UI (точнее, если удаётся не смешивать

) — всё вроде бы нормально.

Здравствуйте, Sinix, Вы писали:

MM>>использовать ее с несколькими контролами одновременно.
S>Ок, а зачем? Можно примеры, когда недостаточно создания своего контрола/юзер контрола? Реально интересно, обещаю не спорить и не холиварить

Например, для функции Window | Split. Согласен, что нужно редко.

MM>>жестко привязывает нас к WPF-ному дереву наследования.
S>А как иначе? Если не смешивать поведение приложения и поведение UI (точнее, если удаётся не смешивать

) — всё вроде бы нормально.
У нас очень большая часть поведения приложения — это поведение UI. Сейчас у нас есть ViewModel, которую при желании можно применить и в Windows Forms и в вебе. Если я перенесу ее код в класс, унаследованный от System.Windows.Controls.Control, реюзабельность окажется под вопросом.

Вставлю свои пять копеек.
1.В моделях прописываются правила, на основе которых строится отображение, но никак не параметры самого отображения.(привет различным panel1 и т.д.).
В текущем проекте стараюсь придерживаться именно подобной концепции.Для игр со всякими panel1 использую usercontrols, имплементированные в шаблон для VM.

2. При проектировании надо четко придерживаться определенных правил. В частности, если в модели появились какие-то UI-specific функции, значит, что-то уже идет не так.

В принципе я понимаю людей, которые предпочитают не отделять мух от котлет и используют user controls(сам так делал года 4 назад). С юзер контролами только одна засада —
их невозможно протестировать в отрыве от UI.А протестировать UI в принципе не такая уж простая задача. Поэтому разделение на модели и представление несет еще одну важную
функцию, о которой тут уже упоминали : разделение тестов. Отдельно мы тестируем логику отображения, и отдельно само отображение(оно может быть разным для одной и той же ViewModel).
Поскольку VM у нас никак не привязана к UI, то писать юнит тесты на нее становится легко и приятно. А ежели еще работать через команды,тогда все получается просто и стройно.
С моей точки зрения проблема MV* фреймворков в пороге вхождения. Пока ты не понимаешь, зачем он нужен и как его использовать, то и писать ты на нем будешь как привык, а не как следует по внутренней логике.
В общем, с моей точки зрения, предмет спора не стоит выеденного яйца. Кому-то нравится, кому-то нет. Я писал по-всякому, с MVVM код получается намного стройнее. Опять же, с моей точки зрения, данный код значительно проще поддерживать и расширять. Уфф.Вроде все написал.

	От:	MaximVK
	Дата:	27.04.11 09:29
	Оценка:	4 (2)

	От:	Codechanger
	Дата:	27.04.11 20:25
	Оценка:

	От:	Sinix
	Дата:	28.04.11 00:53
	Оценка:	4 (1) +1

От:	henson	http://www.njt-rails.com
Дата:	28.04.11 14:10
Оценка:

	От:	Sinix
	Дата:	28.04.11 14:58
	Оценка:	8 (2)

От:	Vladek	Github
Дата:	01.05.11 03:47
Оценка:	8 (2)