Моя компания давно разработала продукт, использующий MFC в Visual C++ в качестве стандарта де-факто для разработки пользовательского интерфейса. Наша кодовая база содержит МНОГО устаревшего / архаичного кода, который необходимо поддерживать в рабочем состоянии. Часть этого кода старше меня (изначально написана в конце 70-х), а некоторые члены нашей команды все еще работают с Visual Studio 6.
Однако, к счастью, внутри компании пришли к выводу, что наш продукт выглядит несколько устаревшим по сравнению с продуктом наших конкурентов и что необходимо что-то делать.
В настоящее время я работаю над новой областью пользовательского интерфейса, совершенно отдельной от остальной части продукта. Поэтому мне была предоставлена возможность опробовать «новые» технологические стеки в качестве своего рода испытательного полигона, прежде чем начнется долгий процесс перехода к остальной части пользовательского интерфейса.
Я использую C# с Windows Forms и инфраструктурой .net какое-то время в свободное время и наслаждаюсь этим, но меня несколько беспокоят головные боли, вызванные взаимодействием. Хотя эта конкретная ветвь пользовательского интерфейса не потребует значительного взаимодействия с устаревшей кодовой базой C++, я могу предвидеть, что это станет проблемой в будущем.
Альтернативой является просто продолжить работу с MFC, но попытаться воспользоваться преимуществами нового пакета функций, поставляемого с VS2008. Думаю, это самый простой вариант, но я беспокоюсь о долговечности и не пользуюсь преимуществом .net ...
Итак, что мне выбрать? Мы небольшая команда, поэтому моя рекомендация, скорее всего, будет принята в качестве будущего направления нашего развития - я хочу понять это правильно.
MFC мертв? C# / Winforms - это путь вперед? Есть что-нибудь еще, что мне полностью не хватает? Помощь очень признательна!
Если вы захотите перейти на 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 с несколькими экземплярами - это может быть для нас ключевой проблемой!
Модель драйвера дисплея Windows Vista (msdn.microsoft.com/en-us/library/aa480220.aspx), из MSDN
Одна из моих разрабатываемых машин - это Windows XP с двумя мониторами, и я часто вижу на экране несколько приложений WPF. Проблем с производительностью не заметил. Конечно, ни одно из приложений, которые я использую для разработки, не являются настоящими мощными графическими приложениями с большим количеством движущихся объектов. Если бы это было так, проблема совместного использования графического процессора могла бы стать заметной.
Вы не даете много подробностей о том, что делает ваш устаревший код или как он структурирован. Если у вас есть определенные критерии производительности, вы можете сохранить часть своей кодовой базы на C++. Вам будет легче взаимодействовать со своим старым кодом, если он правильно представлен - можете ли вы сегодня вызвать существующую базу кода из C#? Возможно, стоит подумать о проекте, чтобы получить правильную структуру.
Что касается WPF, вы можете возразить, что WinForms может быть более подходящим. Переход на WinForms - большой шаг для вас и вашей команды. Возможно, им будет удобнее перейти на WinForms? Это лучше документировано, больше опыта на рынке и полезно, если вам все еще нужна поддержка клиентов Windows 2000.
Вас может заинтересовать Расширение приложений MFC с помощью .NET Framework
Еще кое-что, что следует учитывать, - это C++ / CLI, но у меня нет опыта с этим.
Спасибо всем за ваши ответы, обнадеживает, что в целом консенсус следует моему мышлению. Мне повезло, что наше программное обеспечение также работает на нашем собственном оборудовании (для индустрии вещания), так что выбор ОС действительно остается за нами, и это делается нашими клиентами. В настоящее время мы работаем с XP / 2000, но я вижу желание в ближайшее время перейти на Vista.
Однако нам также необходимо поддерживать очень точный контроль над производительностью графического процессора, который, я думаю, автоматически исключает WPF и аппаратное ускорение? Я должен был указать на это в своем исходном посте - извините. Возможно, можно использовать два GPU ... но это совсем другой вопрос ...
У команды нет значительного опыта работы с C#, и я сам не являюсь экспертом, но я думаю, что общие долгосрочные преимущества управляемой среды, вероятно, перевешивают время, необходимое для того, чтобы быстро освоиться.
Похоже, что в Winforms и C# он есть на данный момент.
GPU также, похоже, оказывает огромное влияние на использование памяти WPF.
Я не знаю, влияет ли это на вашу ситуацию или нет, но есть по крайней мере одна ситуация, в которой графический процессор вообще не используется при запуске WPF: удаленный рабочий стол (RDP / службы терминалов). Если быть более точным, графический процессор удаленной машины вообще не используется при запуске приложений WPF на нем. В RDP 6.0 примитивы возвращаются клиенту для рендеринга.
Я разработчик приложения, в котором содержится тонна устаревшего кода MFC, и у нас все те же проблемы. Важной движущей силой нашей стратегии было устранение как можно большего количества рисков и неопределенностей, что означало избегание «большого переписывания». Как мы все знаем, TBR в большинстве случаев дает сбой. Поэтому мы выбрали инкрементный подход, который позволяет нам сохранять модули, которые не будут меняться в текущем выпуске, писать новые управляемые функции и переносить функции, которые получают улучшения для управления.
Сделать это можно несколькими способами:
Размещайте содержимое WPF в представлениях MFC (см. здесь)
Для приложений MFC MDI создайте новую платформу WinForms и разместите свои представления MFC MDI (см. здесь)
Размещение пользовательских элементов управления WinForms в диалогах и представлениях MFC (см. здесь)
Проблема с внедрением WPF (вариант 1) заключается в том, что вам потребуется переписать весь пользовательский интерфейс сразу, иначе это будет выглядеть довольно шизофренично.
Второй подход выглядит жизнеспособным, но очень сложным.
Третий подход - это тот, который мы выбрали, и он очень хорошо работает. Это позволяет вам выборочно обновлять области вашего приложения, сохраняя при этом общую согласованность и не касаясь того, что не сломано.
Пакет Visual C++ 2008 Feature Pack выглядит интересно, хотя я с ним не играл. Похоже, это может помочь с вашей проблемой устаревшего внешнего вида. Если «лента» будет слишком раздражать ваших пользователей, вы можете посмотреть на сторонних поставщиков средств управления MFC и / или WinForms.
Моя общая рекомендация состоит в том, что взаимодействие + инкрементное изменение определенно предпочтительнее радикальных изменений.
Прочитав ваше продолжение, я могу определенно подтвердить, что повышение производительности фреймворка значительно перевешивает вложения в его изучение. Никто в нашей команде не использовал C# в начале этой работы, а теперь мы все его предпочитаем.
Вы можете оформить свой WPF так, чтобы он выглядел как старые элементы управления стилем.
Усилия / отдача от этого мрачны. Не говоря уже о том, что никогда заставит его выглядеть попиксельно правильно. Вы получите эффект «сверхъестественной долины».
Получение пиксельных стилей WPF могло занять много времени, НО в считанные часы я смог получить стили одного приложения настолько точными, что никто - даже специалисты QA - не понял, что новые разделы немного отличаются.
Да, MFC мертв. WinForms умирает. На данный момент путь вперед - WPF. Переход с MFC на WinForms существенно сократит расходы, но переход с WinForms на WPF значительно сократит расходы. WinForms - хороший вариант для людей, которым все еще требуется поддержка компьютеров с Windows 2000 или Windows Mobile. DirectX по-прежнему лучше всего подходит для 3D-игр и САПР. IMHO, всем остальным следует полностью пропустить WinForms и перейти непосредственно к WPF.