Будущая коррекция большого приложения пользовательского интерфейса - 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 уменьшается, а С# растет.

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