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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Похоже, что в Winforms и C # он есть на данный момент.

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

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

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

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