Будущая коррекция большого приложения пользовательского интерфейса - MFC с пакетом Feature Feature 2008, или С# и Winforms?

Моя компания разработала долговременный продукт с использованием MFC в Visual С++ в качестве стандарта defacto для разработки пользовательского интерфейса. Наша база кода содержит ALOT устаревшего/архаичного кода, который должен поддерживаться. Некоторые из этого кода старше меня (изначально написанные в конце 70-х), а некоторые члены нашей команды все еще находятся на Visual Studio 6.

Однако, к счастью, был сделан вывод о том, что наш продукт выглядит несколько устаревшим по сравнению с нашими конкурентами, и что что-то нужно сделать.

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

Я использую С# с Windows Forms и .net в течение некоторого времени в свободное время и наслаждаюсь этим, но я несколько обеспокоен головными болями, вызванными interop. Хотя эта ветка пользовательского интерфейса не потребует большого взаимодействия с устаревшей кодовой базой С++, я могу предвидеть, что это станет проблемой в будущем.

Альтернативой является просто продолжить работу с MFC, но попытайтесь воспользоваться новым пакетом функций, который поставляется с VS2008. Это, я думаю, самый простой вариант, но я беспокоюсь о долговечности и не пользуюсь добротой, которая есть .net...

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

МФЦ мертв? Является ли С#/Winforms способом продвижения вперед? Есть ли что-то еще, что я совершенно не хватает? Помогите с благодарностью!

Ответ 1

Я разработчик приложения, у которого есть тонна старого кода MFC, и у нас есть все те же проблемы. Большим драйвером нашей стратегии было устранение как можно большего риска и неопределенности, что означало избежать "Большой перезаписи". Как мы все знаем, TBR терпит неудачу большую часть времени. Таким образом, мы выбрали инкрементный подход, который позволяет нам сохранять модули, которые не будут меняться в текущей версии, записывая новые функции, управляемые и поддерживающие функции, которые получают улучшения для управляемого.

Вы можете сделать это несколькими способами:

Содержит содержимое WPF в ваших представлениях MFC (см. здесь)
Для приложений MFC MDI создайте новую среду WinForms и разместите свои представления MDI MDI (см. здесь)
Пользовательские элементы управления Host WinForms в диалогах и представлениях MFC (см. здесь)

Проблема с принятием WPF (вариант 1) заключается в том, что вам потребуется переписать весь ваш интерфейс сразу, иначе он будет выглядеть шизофреником.

Второй подход выглядит жизнеспособным, но очень сложным.

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

Visual С++ 2008 Feature Pack выглядит интересно, но я не играл с ним. Похоже, это может помочь в вашей проблеме устаревшего взгляда. Если "лента" будет слишком раздражать для ваших пользователей, вы можете посмотреть сторонние производители MFC и/или WinForms.

Моя общая рекомендация заключается в том, что interop + incremental change определенно предпочтительнее радикальных изменений.

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

Ответ 2

В зависимости от приложения и желания ваших клиентов устанавливать .NET(не все из них), я определенно перейду к WinForms или WPF. Взаимодействие с кодом С++ чрезвычайно упрощено путем рефакторинга кода, отличного от UI, в библиотеки классов с использованием С++/CLI (как вы отметили в своем выборе тегов).

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

Мое предложение - узнать, что используют ваши клиенты. Если большинство переместилось в Vista, и ваша команда готова внести много работы с графическим интерфейсом, я бы сказал, пропустите WinForms и перейдите в WPF. В противном случае, безусловно, серьезно посмотрите на WinForms. В любом случае библиотека классов в С++/CLI является ответом на ваши проблемы взаимодействия.

Ответ 3

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

Что касается WPF, можно утверждать, что WinForms может быть более уместным. Переход на WinForms - большой шаг для вас и вашей команды. Возможно, им может быть удобнее переходить на WinForms? Это лучше документировано, больше опыта на рынке и полезно, если вам все еще нужно поддерживать клиентов Windows 2000.

Вам может быть интересно Расширение приложений MFC с .NET Framework

Что-то еще нужно рассмотреть С++/CLI, но у меня нет опыта с ним.

Ответ 4

Если бы вы перешли на С# и, следовательно,.NET, я бы рассмотрел Windows Presentation Foundation, а не WinForms. WPF - это будущее умных клиентов в .NET, и навыки, которые вы получаете, вы сможете повторно использовать, если хотите сделать приложения Silverlight с помощью браузера.

Ответ 5

Благодарим всех вас за ваши ответы, и это обнадеживает, чтобы понять, что в целом консенсус следует моей линии мышления. Мне повезло, что наше программное обеспечение также работает на нашем собственном оборудовании (для индустрии вещания), поэтому выбор ОС действительно является нашим и нацелен на наших клиентов. В настоящее время мы работаем с XP/2000, но я вижу желание быстро перейти к Vista.

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

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

Похоже, что у Winforms и С# есть это сейчас.

Ответ 6

Я согласен с настроем WPF. Пользовательский интерфейс с тегом /XML будет казаться немного более переносимым, чем WinForms.

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

Может быть, какой-то поэтапный подход будет возможен? Я участвовал в перекодировании устаревших приложений на С# совсем немного, и это всегда занимает намного больше времени, чем вы бы оценили, особенно если вы сохраняете какой-то унаследованный код, или ваша команда не так знакома с С#.