Начитался Composite Client Application Guidance . Решил применить прочитанное в разрезе MVVM. Что-то вроде почти тоже самое получается и без всяких CAL :) Тестовый проект в аттаче, если кому интересна зарисовка с парой страниц и парой кнопок. Для компиляции нужен установленный Unity Application Block 1.2 .

Да, запостил к тому, что поругайте, кому не лень :)

SeVaНеплохо,читал не зря,но замечания есть.Завтра напишу

Там проект, что называется "в процессе". Рефакторингом занялся. Вынес управление приложением в отдельный класс, добавил очистку сессии и т.п.

Улучшенный вариант в аттаче.

Еще вариант. Добавлено некое подобие именованных регионов (в оболочке их объявлено два - MainRegion и HeaderRegion). Правда, пока сам не до конца понимаю, как ими управлять. По идее, надо или для каждого компонента (в самом компоненте) выбирать регион, в котором рисоваться, или, для каждого компонента мутить свой вложенный контейнер, в котором выделять предназначенный для его размещения регион.

С регионами частично разобрался. Вот таким вот способом можно указать регион в предыдущем варианте проекта.

Если кому еще интересно, то продолжение будет на codeplex .

Все остальное позже почитаю.

SeVa- дай ссылку на Unity в codeplex c более новым и улучшенным вариантом

Здесь не понял. У меня ссылка на Unity вроде правильная. 1.2 для WPF Октябрь 2008 последняя официальная версия :) Есть еще для сервелата декабрьская, но у меня не сервелат :)
Видел упоминания о 2.0, но найти смог только какие-то отдельные куски кода...

SeVa,

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

SeVaобычно создают отдельный сервис для диалоговых окон,тогда


А вот вопрос тогда - у меня почти все так как ты описал. Но часть представление размазана по нескольким регионам. Например, эксплорер - в нем отображаю фотографии с дисков клиента, а элементы управления в стороне от основного места событий висеть должны. Как быть в такой ситуации?

SeVaОпиши подробней.Какие элементы управления и что должно происходить?

Область по центру окна. В нем wrap-панель с фотографиями / папочками / дисками. И в разных местах окна - управление навигацией и т.п. в перемежку с кусками дизайна, относящимися к другим модулям. В прошлой версии у меня был источник данных с отдельным представлением с кнопочками, строкой для ввода пути и т.п. А в текущем варианте что-то не соображу - это должны быть так же разные представления (эксплорера и источника данных)? Хотелось бы все в один модуль как-то увязать, но что бы можно было указать пункт назначения, где что отображать :)
PS: Может сумбурно объяснил... я имею в виду, вариант с диалоговым окном - у меня получается несколько представлений и моделей представлений в одном модуле и в вариант с "OpenPopupWindow()" оно совсем, на мой взгляд, как-то не ложится :)

SeVaСделай вариант и для SL,посмотри "Multi-Targeting QuickStart ".C FlowControl,DeepZoom можно будет сделать конфету и 400Мб народу устанавливать не нужно будет.

DeepZoom использовать не получится - его надо заранее расчитывать, насколько я помню.
Под SL хотел сделать, но как-то руки все не дошли. Тут доступ к дискам клиента нужен - под SL придется что-то типа сервиса доступа к файловой системе мутить... или веб-сервер а-ля WCF REST, и уже из этого сервера показывать файлы в виде картинок в SL.

SeVaСкоро тоже собираемся прикручивать изображения,поделись,как с ними боролись.

Для чтения картинок с медленных устройств (а они почти все значительно медленнее жесткого диска) - писал обработчик очередей (точнее, стека) сообщений - для каждого носителя свой стек.
Для отображения картинок рисовал свою VirtualizedWrapPanel - клиенты любят притащить весь свой архив фотографии сложенный в корень DVD-диска, а память она ж не резиновая. Особенно под x86 с его лимитом в 2Гб. Скоро блюреи начнут такие с собой таскать... готовлюсь - рисую новую версию, которая будет быстрее, выше, сильнее И, кстати, насчет SL - думаю, в данной ситуации, он был бы немного в выйгрыше...
Еще про картинки - в windows 7 майкрософты поправили глюк с zip-ованными тифами, в XP и Vista править, насколько я понял, ни кто не собирается. Плюс, утечки памяти при работе с майкрософтовской графической библиотекой победить получилось только через выделение отдельного домена для сессии и последующего его убивания. Поэтому, имхо, правильный выбор - ImageMagick и ему подобные наборы.

SeVaКажется, вы использовали FileStream, какие впечатления о нем,насколько устойчиво работает,есть ли грабли?По тестам для изображений больше чем 2Мб он на порядок быстрее.

По FileStream - работает со скоростью дисковой подсистемы, стабильно, быстро. Только вот версионность данных мне не совсем нравится - после удаления файла (база в SimpleMode) место на диске может до нескольких часов занятым оставаться, пока сервер не соизволит его почистить от мусора. И если записывать данные поверх старых, то все копии лежат так же долго.
Ну и, собственно, гоняли его пока только в плотном тестовом режиме - только в новой версии программы все файлы будут на него напрямую сливаться.
По скорости и надежности от просто файловой системы ни чем не отличается, если не считать транзакционную целостность синхронную с данными. Ибо, читаешь все равно с файловой системы напрямую - от сервера только путь получаешь. В общем, filestream я бы порекомендовал :)

SeVaОпиши по шагам,что может делать пользователь,подумаем,как это удобней скомпоновать
У меня тут дизайн готовый лежит :) Вот думаю, как сделать лучше. Тут набор страниц что-то типа карусельного мастера. Несколько модулей:

- приветствие + регистрация пользователя,
- редактор заказа а-ля макдональдс, с горой кнопок типа водопада - при выборе одной кнопки ниже появляется новая строка с кучей новых кнопок,
- эксплорер для выбора файлов (доступен из редактора заказов и с отдельной большой кнопки в левом верхнем углу экрана + в том же углу пара кнопок для перемещения по истории эксплорера "вперед" - "назад"),
- простенький фоторедактор (повернуть, обрезать, глаза красные убрать и т.п.),
- страница для просмотра заказа и цены,
- справка на все случаи жизни,

при этом нужно обеспечить:

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

Сначала TabControl прикрутил и тупо табы в нем переключал при переходе со страницы на страницу. Нравилось до тех пор, пока дизайнеры кнопки не начали по всему экрану растаскивать Стал думать про регионы и управление ими. Вышел на CAB, затем на Prism. Покрутил - идея понравилась, реализация - не очень Хотя, может, я что-то не до конца в них понял? Вариант написать новую программу и под WPF и под SL два в одном очень даже... хотя можно просто в SL - ни кто и не заметит, что сервер локально на машине стоит

SeVaавторТут доступ к дискам клиента нужен - под SL придется что-то типа сервиса доступа к файловой системе мутить... или веб-сервер а-ля WCF REST, и уже из этого сервера показывать файлы в виде картинок в SL
В SL есть FileOpenDialog,ничего мутить не нужно.

а) FileOpenDialog кастомизации не поддается (по крайней мере, я не нашел, как это можно сделать)
б) FileOpenDialog показывает все диски, а нужны только диски пользователя (даже не интересовался - может у него и есть какие-то надежные фильтры, которые пользователю не обойти)
в) FileOpenDialog не показывает информацию из exif
г) FileOpenDialog is PopUp, что, дизайнеры считают, моветон и будет мешать клиентам наслаждаться моментом заполнения заказа
д) каждый отображаемый клиенту файл должен выглядеть так, как он будет напечатан (Crop + правильное цветовое пространство + рамки + размеры и т.п.) - думаю, в FileOpenDialog проблемно будет затолкать.
е) Память. Сколько ее отъест FileOpenDialog - для меня загадка. Надо как-нибудь будет попробовать скормить ему DVD с фотографиями.

Для всего этого в предыдущей версии я использовал самописный асинхронный DataSourceProvider, самописный VirtualizingWrapPanel с виртуализацией UI и данных, и самописный стек (очередь) заданий для медленных дисков. Все это есть, но работает немного кривовато. Например, с клавиатуры невозможно управлять прокруткой для VirtualizingWrapPanel, очереди иногда застревают на несколько минут на битых файлах :)

SeVaавторDeepZoom использовать не получится - его надо заранее расчитывать, насколько я помню.
Правильно,нужно,но несложно.
А я про сложность и не говорил :) Речь о времени расчета.

SeVaЭта программа для пользователей сервиса?Или для работников конторы?
И для тех и для других. Наборы модулей будут немного различаться и компоновка объектов на экране.

Добавлю еще маленькую деталь. Это киоск. То есть, программа стоит вместо шелла.

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

Для чего использовать? Лучше тогда бэкэнд написать...

SeVaавторА я про сложность и не говорил :) Речь о времени расчета.
Для 6Г не пробовал,для нескольких фотографий тормозов не заметил.На codeproject есть готовый пример.
Что вы используете для чтения exif? ФОто грузите на сервер? Если да,то каким способом?

В новой версии exif будет разбирать ImageMagick
В старой - BitmapMetadata, но он иногда врет.

Сейчас фото грузятся сначала в %temp% на локальной машине, затем переливаются на сервер. Даже страничка такая есть "подождите, пока файлы скопируются на сервер". Хочу сделать сразу в локальную базу, а затем, по запросу сервера,- на сервер.

Насчет тормозов для нескольких фотографий - если с диска локальной машины, то скорость вполне устраивает. Тем более, что больше одного файла одновременно не гружу. А вот если с DVD, то процесс может затянуться вплоть до нескольких часов. Особенно, если много мелких файлов и диск поцарапанный.