Каковы некоторые методы для переноса большого приложения MFC в WPF / .NET?

Question

В настоящее время я работаю над очень большим устаревшим приложением MFC MDI. Он имеет большое количество элементов пользовательского интерфейса - закрепляемые панели инструментов, настраиваемые элементы управления деревом, контекстные меню и т. Д. Это приложение для обработки изображений, поэтому основные виды визуализируются с использованием DirectX и OpenGL. Этому продукту около 10 лет, и одним из приоритетов здесь является обновление внешнего вида.

Зная, что Microsoft проделала хорошую работу по обеспечению взаимодействия между C ++ / MFC и .NET, я подумала, что имеет смысл постепенно перемещать базу кода. Сейчас я борюсь с тем, с чего начать.

Один из подходов состоит в том, чтобы разорвать инфраструктуру MFC с помощью WPF и повторно использовать как можно больше кода C ++. Это позволит нам максимально использовать преимущества архитектуры WPF, но будет означать длительный период разработки, пока мы снова не станем полностью функциональными.

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

Или есть другой вариант, которого я здесь не вижу?

Будем благодарны за любые предложения или ссылки на информацию по этой теме.

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

1) Будущее развитие продукта

Этот продукт все еще активно разрабатывается с новыми функциями, добавляемыми на регулярной основе. Я думал, что было бы много смысла попытаться медленно перейти к C # / WPF. Из моего ограниченного опыта работы с C # / WPF я обнаружил, что прирост производительности поразителен по сравнению с работой в C ++ / MFC.

Другая важная вещь, которую мы получаем с WPF, - это возможность использовать преимущества многоголовых систем. Приложения MFC ограничены одним фреймом верхнего уровня, что затрудняет использование нескольких мониторов.

2) Удержание и набор сотрудников

Становится все труднее находить разработчиков, которые готовы работать на MFC. Для развития карьеры нынешних разработчиков также важно познакомиться с новыми технологиями.

Answer 1

Возвращаясь к этому, потому что я успешно заменил наш пользовательский интерфейс MFC верхнего уровня (основной фрейм, окна и панели инструментов) на WPF.

Как оказалось, наш базовый код рисования просто должен быть передан HWND для рендеринга. Это позволило очень легко повторно использовать основную часть нашей существующей кодовой базы C ++.

Вот краткое изложение ключевых элементов подхода, который я выбрал:

• Использовал класс .NET HwndHost для размещения HWND для кода рисования C ++ для визуализации в
• Создал оболочки C ++ / CLI для любого собственного кода C ++, который должен быть доступен для кода пользовательского интерфейса WPF / C #
• Оставил большинство диалогов MFC как есть в собственном коде C ++. Это минимизирует объем работы, необходимый для завершения пользовательского интерфейса. Со временем диалоги MFC могут быть перенесены в WPF.

В качестве дополнительного примечания мы используем SandDock и SandRibbon из Divelements и до сих пор очень довольны ими.

Answer 2

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

Не желая показаться негативным: ты уверен, что это будет стоить усилий? Если бы я писал большое приложение с нуля, я бы сейчас не начинал с C ++ и MFC, но, увидев, где вы находитесь, что вы действительно выиграете от его переписывания? Будет ли добавлена ​​новая функция, за которую пользователи будут платить? Есть ли пользователи, которых вы отключите, которые не смогут запустить новую версию? Я не могу не подозревать, что вы получите гораздо большую отдачу от инвестиций, если посмотрите на некоторые относительно простые вещи, которые вы можете сделать, чтобы улучшить внешний вид приложения. Например, есть ли у него манифест в стиле XP, чтобы общие элементы управления выглядели как XP? Неужели несколько дней, потраченных на обновление битов (например, с помощью диалоговых окон файлов нового стиля), дадут вам большую часть пути к блестящему новому облику? Имейте в виду, что даже самый новый и блестящий Office 2007 был реализован Microsoft с обычными элементами управления Win32.

Answer 3

FWIW, тем временем, вы можете использовать MFC Feature Pack (доступный с VS2008 SP1), чтобы придать вашему приложению Office 2007 внешний вид и чувствовать себя довольно быстро (вы даже можете добавить ленту, если это то, что ваши пользователи хотели бы, хотя это будет более сложным делом.) Я обновил пользовательский интерфейс для старого приложения MFC, используя эти новые классы, за один день, и теперь, если честно, это выглядит фантастически, и мои пользователи очень довольны (вы можете поддерживать целый ряд образов) и цветовые схемы.) MS выбрала набор инструментов BCG, но есть и другие, доступные, если вы хотите заплатить небольшую сумму денег (например, CodeJock.)

Я знаю, что это не отвечает на ваш вопрос, но если вам нужны только изменения пользовательского интерфейса, возможно, стоит посмотреть.

Answer 4

Раньше мне приходилось делать то же самое в проекте, использующем WinForms. Нам нужно было перенести наш проект MFC на .NET 1.1, и мы решили взять все основные функции приложения MFC и написать управляемые оболочки вокруг всех них. Затем мы написали интерфейс для WinForms и по крупицам подключили старый код C ++. Я думаю, что мы сделали правильный выбор в долгосрочной перспективе. Я не представляю, как бы мы это сделали, если бы попытались сохранить интерфейс MFC одновременно.

Answer 5

Я думаю, вы хорошо разбираетесь в стратегиях. Обратите внимание, что одной из потенциальных проблем при переходе на WPF является то, что не у каждого элемента управления есть дескриптор. К сожалению, это самый неуклюжий сценарий взаимодействия. AFAIK, единственный способ взаимодействия с MFC и WPF - пройти через WindowsFormsHost . Парадигма WPF также радикально отличается от MFC / WinForms, поэтому там могут быть некоторые проблемы с переводом.

Учитывая вашу большую, но функциональную, унаследованную кодовую базу, я бы, вероятно, поспорил в пользу вашего второго подхода. Начните с одного элемента управления за раз и сделайте его WPF-у. Создайте четко определенный интерфейс между новым управляемым элементом управления и базовой кодовой базой, а затем работайте с этим интерфейсом. Если вы делаете это по одному, вы будете работать с более низкой характеристикой риска: кривая обучения WPF (что довольно круто, imho).

Мне кажется, важно отметить, что я бы, вероятно, предложил бы первый подход, если вы собираетесь использовать WinForms. Более тесная парадигма и относительно гладкая кривая обучения было бы намного проще работать в одночасье.