Предположим, что два разработчика (Иванов и Петров) решили совместно написать некую простенькую программу. Один разработчик (Иванов) берётся писать ядро приложения на .NET-языке (пусть это будет C#), используя для этого в качестве инструмента Visual Studio 2008 SP1. Второй (Петров) – разрабатывает GUI посредством технологии WPF, задействовав для этого новые инструменты от Microsoft Studio: Expression Blend и Expression Design. 
Работа должна вестись параллельно. Т.о., как я понимаю, разработчики должны изначально договориться о реализации классами, формирующими GUI некоего заранее продуманного набора интерфейсов.

пока Петров создает GUI, реализовывая параллельно оговоренные интерфейсы, Иванов во всю создает ядро программы, оперируя озвученными выше интерфейсами. Когда он получит от дизайнера GUI - просто включит его в свой проект и будет юзать его.

Изначально я ожидал, что Expression Blend на выходе мне выдаст XAML-файл, который я добавлю в свой cs-проект, запущу некую утилиту, которая преобразует мой XAML в BAML (т.е. автоматом создаст cs-файл с кодом). А поскольку Иванов с Петровым заранее договорились, о наборах интерфейсах, которые необходимо реализовать и которые реализовал Петров, то получается, что все вроде должно состыковаться бесшовно. 

Однако по факту, поковырявшись в  Expression Blend, я обнаружил, сто он создает что-то похожее на конечное приложение (exe-файл)...  Этого момента я не понял...


Это сообщение отредактировал(а) Compositum - 30.3.2009, 17:11

GUIшник реализует интерфейсы?   
Гуишнику по-хорошему программирование вообще знать не обязательно...дело гуишника - рисовать гуй и всё...

Потом просто берётся гуй в виде XAML-файла и его code-behind  в виде сопутствующего *.cs-файла и они втыкаются в проект, после чего благополучно через обработчики нужных событий соединяются с движком...

видимо имелось ввиду UI

knox, окей) Какая разница между UI и GUI? )

[QUOTE=Partizan,30.3.2009,  17:40]
Аке, задам вопрос более развернуто.
Я разработчик, пишу ядро. Вы - дизайнер, создаете GUI.
Предположим, я создаю метод, удаляющий указанные пользователем телефонные номера. Этот метод принимает в качестве параметра некий List<string>phoneKeys, являющийся коллекцией "ключей" телефонных номеров, выбранных пользователем в созданной вами форме.  Я понятия не имею, какой контрол вы используете для предоставления юзеру возможности сделать этот множественный выбор: TreeView, ListView или еще какой... Мне нужно, чтобы при выборе юзером нескольких телефонных номеров и выборе им из контекстного меню соответствующей команды эти номера удалялись. 
Если бы у меня был на руках некий IMyInterface, который, как мне известно, реализован в создаваемом вами GUI, я бы без проблем решил бы этот момент на раз элементарной подпиской на некоторое объявленное в этом интерфейсе событие: OnNumbersDelete (object sender, List<string> phoneKeys);
Ежели вы не реализовываете контрактов, как я могу работать параллельно с вами, ежели не знаю имен свойств, событий и методов ваших объектов, которые мы могли бы заблаговременно оговорить посредством интерфейсов?

Compositum, все эти интерфейсы - это дело кодера, а не юайщика...юайщик должен "сделать в соответствии с требованиями, но красиво"...всё...сделал он это...и результат своей работы отдал в виде XAML...всё остальное - забота кодера...

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




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

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

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

Как-то давно, я видел презентацию по семейству expression. Там популярным английским языком говорили о некоем разрыве который существует между девелопером и дизайнером. Суть сводилась к следующему:
1. Дизайнер рисует визуальное представление UI в expression design.
2. Девелопер пишет код в студии.
3. Интегратор привязывает код к UI в expression blend.

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

Прямо MVC какой-то   

UI не обязательно графическим может быть

knox, в общем случае - да... но теперь можно увидеть, что тема в разделе WPF...о како неграфическом интерфейсе может идти речь? )

Это сообщение отредактировал(а) Partizan - 30.3.2009, 21:49

Видите ли, я хочу отделить слой GUI от ядра с тем, чтобы можно было бы, при желании, с лёгкостью заменить один GUI на другой. Для реализации этого каждый GUI должен реализовывать четкий, ранее определенный интерфейс. Недавно я реализовал подобный подход, причем с лёгкостью на раз менял GUI WPF на GUI Win Forms и обратно. И всё это благодаря именно работе посредством интерфейсов. Я создал набор своих классов, которые инкапсулировали нужные мне графические компоненты, а обращение к оным осуществлялось именно посредством интерфейсов. То, что в WIN Forms я реализовал как ListView, в WPF я реализовал посредством TreeView (ибо при таком подходе совершенно не важно посредством какого контрола будет вестись диалог с пользователем). Но никаких проблем в работе не возникло, ибо четко оговорённый интерфейс - краеугольный камень порядка. Да, приходится потратить некоторое время на его реализацию, однако должен заметить - время не такое уж и большое. А результаты того стоят, уж поверьте мне!
Повторюсь: я не должен знать, посредством какого контрола реализован тот же список телефонов юзера (на примере описанном мною выше). Это должно быть на усмотрение дизайнера. Однако для того, чтобы реализовать оговорённый интерфейс, больших знаний в области программирования не требуется. Я не согласен, что дизайнер должен выдавать мне, как программисту не законченный продукт, мол я сам должен дорабатывать его (хотя, в принципе, мне это не составит труда). Равно как и не согласен подключать к этому еще некое третье лицо (не вижу в этом смысла). Просто я за то, что каждый специалист должен выдать требующуюся от него деталь нашего механизма в полностью завершенном виде. Чтобы как только мы их состыковали - все заработало. ИМХО это правильно. 
Я сторонник организации взаимодействия компонентов приложения посредством реализации заранее оговоренного набора интерфейсов. Это гибкий подход. 
Когда компании заключают между собой соглашения, они стараются по максимуму четко прописать контракты (договоры). И это не просто так. В программировании это тоже работает. Но, к сожалению, не все это осознают.... =((((

Привет всем.
Можно и я вставлю свои пять копеек.   

Сейчас в вышке как раз занимаюсь групповой реализацией проекта для одного предприятия.
Проект учебный, но для реального предприятия и требования реальные. Если все сделаем нормально, то предприятие будет использовать нашу программу.
В группе четыре человека. Мы должны пройти весь цикл создания программы: планирование, анализ, проектирование, кодирование, имплементация и пост имплементация.
Первые три стадии проекта прошли с горем попалам. Сейчас занимаемся кодированием. Потом будем рисовать (создавать) GUI и потом его стыковать с кодом.
Приложение разрабатываеться трехслойным: слой доступа к данным, слой бизнес логики и слой представления. Так как мы все учимся на программистов, то каждый должен что-то сделать на каждой стадии реализации проекта по каждой его части. У нас нет разделения на аналистов,кодеров и дизайнеров.

Так что я собственно хочу сказать.

После появления Expression можно полностью разделить труд программистов и дизайнеров при создании WPF(Silverlight) приложений. Проект приложения можно одновременно открыть и в студии (VS 2008) и в Blend-е. 
Как правильно отметил Partizan, главное это 

Т.е. ТТЗ и документированные договоренности между разработчиками.
Это значит, если бы мы делали проект в WPF и было разделение на кодеров и дизайнеров, то пока одни в студии реализуют слои для доступа к данным и бизнес логики, другие в Blend-е создавали бы GUI.
После того как DAL и BL созданы их надо привязать к GUI, для этого открываеться проект в студии (все что насоздавали дизайнеры студия показывает без проблем, в принципе и дизайнер в Blend-е видит код C#) и пишеться код для окон или страниц с использованием слоя BL.
При необходимости дизайнер может тут же править GUI программы открыв прект в Blend-е. И после компиляции все его изменения видны в студии и наоборот.

Compositum, 
попробуй открыть один и тот же проект в студии и в Blend-е. И поэксперементируй с изменением дизайна и кода (С#).

Я открывал в студии GUI, созданный мною же в блэнде. Это не вопрос. =)
Требования... А разве интерфейс - это не четко оговоренное требование? =))))) 
Это оно самое и есть! Причем на самом совершенном уровне. 
ИМХО.

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



Мои слова этому никак не противоречат...



Работа дизайнера/UIщика - нарисовать дизайн...он знает XAML, но вообще не знает программирования...ему это просто не нужно...его дело рисовать, а не программировать....весь code-behind с движком ложится на плечи программиста... UI - готовый продукт работы юайщика. И представляется он именно XAML-кодом...




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



  
Вас беспокоит то, что не все это осознают? Хотите об этом поговорить?   

Добавлено через 9 минут и 15 секунд


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

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


з.ы. само собой требования на более низких уровнях имеют право на существование...

з.з.ы. вопрос-то конкретно в чём? а то "я хочу сделать так, потому что это хорошо"..ну делайте  никто вроде не возражает 
что затруднение-то вызывает?

Compositum, 

А в чем, позвольте вас спросить, заключаеться незаконченность продукта, предоставленного дизайнером?
Он согласно ТТЗ нарисовал вам в Blend-е пользовательский интерфейс. Всё-с батенька. Он свою работу сделал.
Теперь ваша очередь сделать этот интерфейс активным. И делаете это вы прописывая в коде события для элементов пользовательского интрефейса.

Повторюсь, задача (РАБОТА) дизайнера нарисовать вам картинку (при необходимости со встроенной анимацией) в Blend-е и НИЧЕГО более.

не то, чтобы затруднение... Я ожидал, что в бленде, после создания 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 придаёт больше гибкости...