Постепенное портирование приложения PowerBuilder/C++ на C#/WPF или Winforms

Question

У меня есть шанс начать портирование устаревшего приложения, написанного на C++/Powerbuilder, на C#. У нас есть функция этого спринта, которая запускает независимый диалог, и я только что прошел упражнение по созданию dll CCW для моей управляемой реализации этой функции, которая будет вызываться из C++. Я решил использовать WPF для представлений в моей управляемой DLL. Пока все хорошо, так как я могу взаимодействовать с моим управляемым DL1, включая запуск окна WPF из примера приложения MFC.

Есть несколько причин, мотивирующих эту стратегию:

1. У меня есть куча многократно используемых библиотек управления, которые возникли в результате недавней реконструкции 10-летнего устаревшего приложения.
2. Я довольно опытный в C# по сравнению с C++, где я постоянно сталкиваюсь с синтаксисом языка и осмыслением. FWIW, наша компания могла бы лучше инвестировать в некоторые инструменты, хотя это не изменит мою неприязнь к синтаксису C++, заголовочным файлам и несоответствиям... подхода.
3. Для настольных приложений, по крайней мере, для тех приложений, которые мы разрабатываем, я думаю, C# - это путь. 4. В будущем планируется переписать приложение, и я не хочу повторяться, поэтому возникает соблазн начать разрабатывать вещи правильно, где я могу, на этом этапе.
4. У меня нет много помощи C++.

Тем не менее, у меня есть некоторые проблемы и вопросы:

1. Этот частичный подход - путь?

2. С точки зрения производительности, должен ли я взаимодействовать с Winforms вместо WPF? В приложении будет размещаться ГИС, поэтому производительность является ключевым фактором, хотя мы только что разработали другое приложение WPF, в котором установлен MapSuite от ThinkGeo, и оно работает достаточно хорошо. Основное отличие заключается в том, что унаследованное приложение намного интенсивнее ГИС, чем его двоюродный брат WPF.

3. С последними слухами о судьбе WPF/Silverlight, я должен даже рассмотреть WPF? Каковы же альтернативы настольным приложениям, если WPF / Silverlight должен был умереть?

3.Что ждут меня?

Любые мысли и / или советы по этому поводу будут отличными. Я буду консультироваться с моим менеджером по этому вопросу, но сначала хотел бы поделиться некоторыми вашими мыслями и опытом. Тиа.

Клаус

РЕДАКТИРОВАТЬ:

Извините, но заявке 10 лет, а не 25 лет, как было заявлено изначально. Немного перемешать там.

Answer 1

Я не вижу лучшего подхода, чем частичный. И вы всегда можете использовать C++/CLI (он же управляемый C++) для преодоления любых трудных пробелов.

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

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

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