не то, чтобы затруднение... Я ожидал, что в бленде, после создания GUI, идет собственно последняя стадия - реализация интерфейса. Теперь понял - эта стадия делается лишь в Visual Studio после экспорта проекта, созданного в блэнде. 
Аке, ну хоть так... 

п.с. Кстати,  3D-графику где лучше делать? Я так понимаю, что писать ее вручную посредством XAML - повеситься можно, а ежели сделать а AutoCAD - так оттуда нет экспорта в XAML. Как решаете такое?

Да забыл подчеркнуть.
На этапе разработки слоя представления(все детали проанализированны, обговорены и задокументированны):
Работа дизанейра первична.
Работа программиста вторична.

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

Дизайнер нарисовал, Blend записал это кодом XAML в проект.
Теперь программист, открыв проект в студии, видит GUI и может кодировать используемые там контролы.

Т.е. по вашему выходит, что программист должен сидеть и ждать, пока дизайнер создаст GUI?
Т.о. вы завязываетесь на конкретный вариант GUI. А ежели со временем потребуется переделать GUI на другой, позаменяв контролы более новыми аналогами? Вы будете перекраивать ядро? ИМХО ядро вообще, не должно знать, посредством каких контролов представлен GUI. А ежели мы ждем работу дизайнера, значит планируем завязаться на конкретные контролы представленного им GUI?
Поправьте меня, ежели я вас не верно понял...

Насколько я знаю, многие рисуют в редакторах векторной графики типа Adobe Illustrator и т.п. Оттуда можно в xaml экспорт устроить...

Добавлено через 2 минуты и 20 секунд


Compositum, да нет...thomas озвучил очевидную идею, которой сквозит весь топик - объединение логики и представления проходят последним этапом )

по-моему это очевидно 

я не о "рисовании", а именно о создании полноценных 3D-объектов с возможностью их вращения, масштабирования и т.п.

Добавлено через 1 минуту и 44 секунды

Всё, вроде до меня дошло =))))))

тут я вряд ли чем-то смогу помочь...ибо не приходилось...

Есть плагин для 3DS Max, который конвертит в XAML. Вроде даже не один.

Правильные идеи у Compositum'a.Логику и представления можно и нужно делать отдельно.В Prism комманды и события не привязаны к VisualTree и это позволяет создавать слои независимо друг от друга.

xxxSeVa, давай-ка развёрнутый ответ 



Топик читал вообще? Кто-нибудь это оспаривал?



Примеров нам! Тут, я думаю количество Prism-овцев стремится к нулю...так что давай примерами поясняй

Для начала давайте договоримся, что я никому и ничего не должен.

Тут в соседней ветке спрашивали,как создать навороченный грид с тулбаром и строкой состояния.
Кроме одно общего, с ViewModel автоматически подгружается зарегистрированный для него тулбар.
Один из вариантов

Код у него простейший

Во ViewModel задаем обработчики команд

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

Нет проблем, договорились..



WPF он и в Африке WPF...это не особенности Prism, который, насколько я понял, является обычным Pascal-биндингом...
События привязаны к типу...а UI-объекты соответствующих типов лежат в VisualTree...очень странно говорить, что события UI объектов не привязаны к VisualTree   


Всю логику на команды не повесишь... 
Плюс таким образом Вы завязываетесь на WPF UI...
UPD:Такое сопряжение гуя с логикой тоже имеет право на жизнь, но речь тут шла не совсем о том....


AnyWay - код - не работа UI-дизайнера...
код - работа кодера...

Это сообщение отредактировал(а) Partizan - 31.3.2009, 19:36

Именно особенности Prism.Команды и события имеют с обычными только названия.Про Event Aggreragtor можно прочитать у Фаулера.С UI он никак не связан

Эти паттерны придуманы не мной, и для одной простой причины - отделить представление,уйти от спагетти кода и как следствие не ждать дизайнеров.
На UI завязка слабая,можно иметь общий код для WPF и SL,а микса с WinForms есть SCSF со сходным подходом.

Например?Только для бизнес-приложений

xxxSeVa, Да это понятно...но опять повторюсь...речь тут была немного о другом...о том, что код должен писать кодер, а дело дизайнера - нарисовать XAML и всё....



Да, подход приведённый выше позволяет это обойти...но его реализация дело кодера  Дело дизайнера - всего лишь привязывать UI к командам...



Окей...как мы поступим, когда нам важен OriginalSource, от которого пошло событие?

Здесь нет ничего сложного.Событие может иметь параметром любой класс


К слову, в отличии от SCSF,где из песни слов не выбросишь, EventAggregator может использоваться и в WinForms
Еще примеры будут?

xxxSeVa, я о стандартных событиях WPF

Добавлено через 9 минут и 45 секунд
xxxSeVa, я, кстати, сначала подумал про Delphi Prism

соглашусь, что Prism из P&P придаёт больше гибкости...