Проверка будущего большого пользовательского интерфейса - MFC с пакетом функций 2008 или C # и Winforms

Question

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

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

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

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

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

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

МФЦ мертв? Является ли C # / Winforms путь вперед? Есть ли что-то еще, что я полностью пропускаю? Помощь очень ценится!

Answer 1

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

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

1. Размещение содержимого WPF в представлениях MFC (см. здесь )

2. Для приложений MFC MDI создайте новую платформу WinForms и разместите ваши представления MFC MDI (см. здесь )

3. Управление пользовательскими элементами управления WinForms в диалоговых окнах и представлениях MFC (см. здесь )

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

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

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

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

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

---

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

Answer 2

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

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

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

Похоже, Winforms и C # пока что есть.

Answer 3

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

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

Возможно, вас заинтересует Расширение приложений MFC с помощью .NET Framework

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

Answer 4

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

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

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

Answer 5

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

Answer 6

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

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

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