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

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

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

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

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

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

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

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

Да, MFC мертв. WinForms умирает. На данный момент путь вперед - WPF. Переход с MFC на WinForms существенно сократит расходы, но переход с WinForms на WPF значительно сократит расходы. WinForms - хороший вариант для людей, которым все еще требуется поддержка компьютеров с Windows 2000 или Windows Mobile. DirectX по-прежнему лучше всего подходит для 3D-игр и САПР. IMHO, всем остальным следует полностью пропустить WinForms и перейти непосредственно к WPF.

Ray Burns 06.11.2009 08:47
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
12
1
4 042
6
Перейти к ответу Данный вопрос помечен как решенный

Ответы 6

Если вы захотите перейти на 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 - это ответ на ваши проблемы с взаимодействием.

Приведите ссылки на низкую производительность WPF с несколькими экземплярами - это может быть для нас ключевой проблемой!

Andy Dent 27.01.2009 08:19

Модель драйвера дисплея Windows Vista (msdn.microsoft.com/en-us/library/aa480220.aspx), из MSDN

Zooba 29.01.2009 11:39

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

Ray Burns 06.11.2009 08:24

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

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

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

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

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

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

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

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

GPU также, похоже, оказывает огромное влияние на использование памяти WPF.

Aidan Ryan 26.02.2009 01:42

Я не знаю, влияет ли это на вашу ситуацию или нет, но есть по крайней мере одна ситуация, в которой графический процессор вообще не используется при запуске WPF: удаленный рабочий стол (RDP / службы терминалов). Если быть более точным, графический процессор удаленной машины вообще не используется при запуске приложений WPF на нем. В RDP 6.0 примитивы возвращаются клиенту для рендеринга.

Ray Burns 06.11.2009 08:38
Ответ принят как подходящий

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

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

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

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

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

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

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

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

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

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


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

Вы можете оформить свой WPF так, чтобы он выглядел как старые элементы управления стилем.

Andy Dent 27.01.2009 08:18

Усилия / отдача от этого мрачны. Не говоря уже о том, что никогда заставит его выглядеть попиксельно правильно. Вы получите эффект «сверхъестественной долины».

Aidan Ryan 26.02.2009 01:39

Получение пиксельных стилей WPF могло занять много времени, НО в считанные часы я смог получить стили одного приложения настолько точными, что никто - даже специалисты QA - не понял, что новые разделы немного отличаются.

Ray Burns 06.11.2009 08:16

Другие вопросы по теме