Будущая проверка большого пользовательского приложения - MFC с пакетом функций 2008 или C # и Winforms?
https://stackoverflow.com/questions/10901
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Моя компания разработала давно существующий продукт, использующий MFC в Visual C ++ в качестве стандарта defacto для разработки пользовательского интерфейса.Наша кодовая база содержит МНОГО устаревшего кода, который необходимо поддерживать в рабочем состоянии.Часть этого кода старше меня (первоначально написана в конце 70-х), и некоторые члены нашей команды все еще работают в Visual Studio 6.
Однако, к счастью, внутри компании был сделан вывод, что наш продукт выглядит несколько устаревшим по сравнению с продуктами наших конкурентов и что необходимо что-то предпринять.
В настоящее время я работаю над новой областью пользовательского интерфейса, которая совершенно отделена от остальной части продукта.Поэтому мне была предоставлена возможность опробовать "новые" стеки технологий в качестве своего рода испытательного полигона, прежде чем начнется длительный процесс перехода к остальной части пользовательского интерфейса.
Я некоторое время использую C # с Windows Forms и .net Framework в свободное время, и мне это нравится, но меня несколько беспокоят головные боли, вызванные взаимодействием.Хотя эта конкретная ветвь пользовательского интерфейса не потребует особого взаимодействия с устаревшей кодовой базой C ++, я могу предвидеть, что это станет проблемой в будущем.
Альтернативой является просто продолжение работы с MFC, но попробуйте воспользоваться преимуществами нового пакета функций, поставляемого с VS2008.Я думаю, это самый простой вариант, но я беспокоюсь о долговечности и не пользуюсь преимуществами .net...
Итак, что же мне выбрать?Мы небольшая команда, поэтому моя рекомендация, вполне вероятно, будет принята в качестве будущего направления нашего развития - я хочу сделать это правильно.
MFC мертв?Является ли C # / Winforms способом продвижения вперед?Есть ли что-то еще, чего я совершенно не понимаю?Помощь очень ценится!
Решение
Я разработчик приложения, в котором используется тонна устаревшего кода MFC, и у нас у всех те же проблемы, что и у вас.Важной движущей силой нашей стратегии было устранение как можно большего количества рисков и неопределенности, что означало избежание Масштабного переписывания.Как мы все знаем, TBR в большинстве случаев выходит из строя.Поэтому мы выбрали инкрементный подход, который позволяет нам сохранять модули, которые не будут меняться в текущем выпуске, писать новые функции managed и переносить функции, которые улучшаются, в managed.
Вы можете сделать это несколькими способами:
Разместите содержимое WPF в своих представлениях MFC (см. здесь)
Для приложений MFC MDI создайте новую платформу WinForms и разместите свои представления MFC MDI (см. здесь)
Размещайте пользовательские элементы управления WinForms в диалоговых окнах и представлениях MFC (см. здесь)
Проблема с внедрением WPF (вариант 1) заключается в том, что это потребует от вас переписать весь ваш пользовательский интерфейс сразу, иначе это будет выглядеть довольно шизофренично.
Второй подход выглядит жизнеспособным, но очень сложным.
Мы выбрали третий подход, и он работает очень хорошо.Это позволяет вам выборочно обновлять области вашего приложения, сохраняя при этом общую согласованность и не затрагивая то, что не сломано.
Пакет функций Visual C ++ 2008 выглядит интересно, хотя я с ним еще не играл.Похоже, это могло бы помочь с вашей проблемой устаревшего внешнего вида.Если "лента" будет слишком раздражающей для ваших пользователей, вы могли бы обратиться к сторонним поставщикам элементов управления 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 и аппаратное ускорение?Я должен был подчеркнуть это в своем первоначальном посте - извините.Возможно, можно использовать два графических процессора...но это уже совсем другой вопрос...
У команды нет сколько-нибудь значительного опыта работы с C #, и я сам не эксперт, но я думаю, что общие долгосрочные преимущества управляемой среды, вероятно, перевешивают время, необходимое для освоения скорости.
Похоже, что на данный момент это есть у Winforms и C #.
Если бы вы рассматривали возможность перехода на C # и, следовательно, .NET, я бы выбрал Windows Presentation Foundation, а не WinForms.WPF - это будущее интеллектуальных клиентов в .NET, и приобретенные навыки вы сможете использовать повторно, если захотите создавать браузерные приложения Silverlight.
Я согласен с мнением WPF.Пользовательский интерфейс на основе тегов / XML кажется немного более переносимым, чем WinForms.
Я думаю, вам тоже нужно учитывать свою команду, если у вас не так много текущих навыков в C #, то это является фактором, но в дальнейшем рынок разработчиков MFC сокращается, а C # растет.
Может быть, был бы возможен какой-то поэтапный подход?Я довольно часто занимался перекодированием устаревших приложений на C #, и это всегда занимает намного больше времени, чем вы предполагаете, особенно если вы сохраняете какой-то устаревший код или ваша команда не настолько хорошо знакома с C #.
