Мне интересно, есть ли там люди с опытом разработки приложений WPF - и, возможно, более интересно - запуск WPF в процессе производства.
Является ли он достаточно зрелым для использования в более крупных проектах? Каковы очевидные подводные камни? Любые лучшие практики? (Привязка данных в WPF кажется довольно изящной, но работает ли она в реальных проектах?)
Спасибо заранее!
WPF вышел с .NET 3.0. Мы находимся на 3.5 sp1, поэтому, если у него нет готовой MS, у нее много работы. Честно говоря, это было производство готово, когда 3.0 вышел.
В настоящее время я работаю над проектом, который использует WPF для шаблонов и привязки данных (а не для отображения пользовательского интерфейса, но я использую классы пользовательского интерфейса для определения шаблонов). Я также использовал WPF для личных вещей. И, честно говоря, меня пришлось бы избивать, чтобы даже рассмотреть возможность использования оконных форм для пользовательского интерфейса. WPF красив своей простотой и гибкостью. Его устройства для привязки данных впечатляют по сравнению с моделями привязки форм с взломанными кодами. И XAML - революционный шаг в разработке программного обеспечения, imho.
Связывание данных в WPF не просто изящно, но также позволяет реализовать некоторые довольно хорошие архитектурные проекты. Это хороший пост, который охватывает некоторые из наиболее популярных. Подумайте об этом как MVC/MVP на стероидах.
Короче говоря, бегите. Не ходи.
Я не уверен, что он созревает для больших вещей, но он уверен, что готов к приложениям, ориентированным на базу данных среднего размера, если это ваша чашка чая. Я создал систему управления пациентами с использованием WPF + SQL Server 2008 и не имел таких проблем.
Ловушки - у меня есть один - шрифты. Серьезно, как вы объясните своему не-техническому клиенту, что нет ничего, что можно было бы сделать для улучшения рендеринга WPF-шрифтов на XP? Эта область очень болезненна, и не похоже, что Microsoft обращается к ней. (Пожалуйста, поправьте меня, если я ошибаюсь.)
Лучшие практики? Умм, да, вы упоминаете привязку данных, которая работает довольно хорошо, хотя, конечно, она несколько препятствует четкому разделению уровней. На самом деле я думаю, что большая часть идеологии, унаследованной от эпохи WinForms, по-прежнему применяется, если вам удастся задуматься о пользовательском интерфейсе по-разному. Моя лучшая практика для WPF заключалась в использовании генерации кода для создания базы данных в виде ряда элементов управления, хранящихся в WrapPanel. Фактически, эти панели обертывания великолепны, потому что они масштабируются до любого размера экрана, а макет действительно чувствует себя гладким и естественным.
Я бы сказал, да, это готово к производству, и было какое-то время, но есть несколько предостережений:
Говоря о небольшой компании, главной целью которой является получение бизнеса компании в приложении. Должен сказать, что wpf не готов.
Не так просто поддерживать, а не (очень) просто, и разработчики теряют слишком много времени, чтобы получить интерфейс, вместо того, чтобы писать бизнес-код.
Мы возвращаемся к умному клиенту;)
С уважением, Wim
На самом деле я думаю, что ответ да и нет...
Никакая часть моего опыта не была инструментом, доступным для WPF. Сейчас это очень крутая кривая обучения, и одна из вещей, которая отчаянно нужна, - это отличное инструментальное средство для обеспечения доступности технологии, например, уровень интеграции выражения blend/studio и Visual Studio очень низок. Простое задание IMO должно быть простым, и сложные задачи должны быть возможны, поскольку сложные задачи WPF действительно возможны, но простые задачи также сложны.
Сказав все это, если вы пройдете через кривую обучения и сможете справиться с инструментальной платформой, результирующие приложения, безусловно, готовы к производству.
Важно то, что вы должны адаптироваться к WPF, а не пытаться использовать WPF. Вы должны забыть все, что знаете о программировании пользовательского интерфейса (winform или spring). Если вы считаете, что WPF похож на winform, ваша жизнь будет больной... Эта технология готова к производству, это ваш код, который может не быть... Потратьте время, чтобы узнать о хороших практиках программирования в WPF, а ваш код с WPF будет "готов к производству".
Мой опыт работы с WPF в небольшой команде.
Я согласен с Hypo и скажу "да" и "нет".
Я - один из 3 корпоративных разработчиков, мы в спортивной индустрии, и один из проектов - это программное обеспечение для турниров. Недавно я переписал наше приложение для отображения очков/скобок в WPF. Дисплеи на 100% красивее, но это было непросто. Кривая обучения была огромной, исходящей от WinForms, привязка мощная, но равная часть комплекса. У меня много проблем с WPF в VS 2008. Сбой моей среды IDE не реже одного раза в день, мне часто приходится удалять мои пользовательские файлы или открывать свойства в файле проекта, закрывая мою среду IDE. Запуск анимации на XP SP3 кажется гладким только на 50% наших XP sp3 машин, остальные 50% есть тонна уродливых артефактов, и формы, похоже, неправильно перерисовываются. Мой редактор XAML иногда будет волноваться, и мне нужно закрыть вкладку и снова открыть ее. Вся проблема, которую я цитирую, происходит последовательно на четырех разных машинах.
Мой окончательный ответ "да" на "Рамку". Нет инструментам, которые я потратил слишком много времени на борьбу с моей IDE. Нет для небольших команд, которые просто должны получить некоторые быстрые линии бизнес-приложений. Когда есть больше элементов управления, Темы, шаблон проекта, и он работает под VS. Я могу изменить свое мнение.
Несмотря на мое интенсивное обучение PAIN WPF/XAML, он по-прежнему захватывает работу, и я часто увлекаюсь некоторыми из классных вещей, которые вы можете сделать.