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

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

3 голосов
/ 01 июля 2011

У меня есть шанс начать портирование устаревшего приложения, написанного на 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.Что ждут меня Гатчи?

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

Klaus

EDIT:

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

1 Ответ

1 голос
/ 05 июля 2011

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

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

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

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

...