Предположим, что два разработчика (Иванов и Петров) решили совместно написать некую простенькую программу. Один разработчик (Иванов) берётся писать ядро приложения на .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-е и НИЧЕГО более.