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

Question

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

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

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

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

1. Является ли это фрагментарный подход путь?

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

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

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

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

Клаус

EDIT:

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

Answer 1

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

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

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

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