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

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

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

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

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

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

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

MFC мертв? C# / Winforms - это путь вперед? Есть что-нибудь еще, что мне полностью не хватает? Помощь очень признательна!

Ответов (6)

Решение

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

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

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

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

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

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

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

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

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

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


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

Спасибо всем за ваши ответы, обнадеживает, что в целом консенсус следует моему мышлению. Мне повезло, что наше программное обеспечение также работает на нашем собственном оборудовании (для индустрии вещания), так что выбор ОС действительно остается за нами, и наши заказчики делают это самостоятельно. В настоящее время мы работаем с 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#.

В зависимости от приложения и желания ваших клиентов установить .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 , но у меня нет опыта в этом.