Когда я увидел название, я просто собирался скрыться, будучи известным фанатом PB. Ну что ж. Спасибо за вотум доверия, Бернард.
Моим первым предложением было бы отказаться от языка самообмана. Если я съем половину "облегченного" чизкейка, я все равно потеряю свой пояс. Миграция может занять всего 10 минут. То, что вы будете делать, это переписать . Время должно быть измерено как перезапись. риск должен быть измерен как перезапись. И проектное усилие должно быть измерено как переписывание.
Да, я сказал, что усилия по проектированию. «Миграция» вызывает в воображении образы прокачки кода через какой-то черный ящик с переводом, отражающим оригинал, выходящий с другой стороны. Хотите повторить те же ошибки дизайна, которые были допущены в 1994 году, когда вы жили с в течение многих лет? Даже с кодом отличного качества, я предполагаю, что отличный выбор дизайна в PowerBuilder может быть ужасным выбором дизайна в C #. Пропускает ли прямое преобразование мощь и сильные стороны платформы? Будете ли вы жить с последствиями пренебрежения хорошим дизайном C # в течение следующих 15 лет?
Этот спор в сторону, поскольку вы не упоминаете свою мотивацию для перехода "в .NET", трудно предложить, какие варианты вам могут понадобиться, чтобы снизить риск переписывания. Если ваше руководство просто решило, что разработчики PowerBuilder плохо пахнут и должны быть удалены из офиса, тогда удачи в переписывании.
Если вы просто хотите развернуть Windows Forms, Web Forms, Assembly или Web-сервисы .NET или использовать библиотеки .NET, то, как упоминал Пол, переход на 11.0 или 11.5 может привести вас к этому с усилием, близким к миграция. (Я бы рекомендовал еще раз проверить и убедиться, что у вас есть хороший дизайн для новой платформы, особенно с веб-формами, но это усилие должно быть значительно меньше, чем переписывание.) Если вы хотите развернуть приложение WPF, я знаю, год - это достаточно долгое время, но, возможно, стоит взглянуть на PowerBuilder 12. Правильное использование WPF может поставить PowerBuilder в уникальное и мощное положение.
Если гарантированная перезапись будет в вашем будущем (ливни кажутся более дешевыми), возможно, вы захотите поэтапно преобразовать. DataWindow.NET позволяет взять ваши DataWindows с собой. (Моя любимая теория недели заключается в том, что разработчики PowerBuilder принимают DataWindow как должное до тех пор, пока им не придется воспроизводить все встроенные функции.) Возможность добавления уже существующих, предварительно протестированных, многорядных, прокручиваемых, минимальных Огромный ресурс, печатный, динамический пользовательский интерфейс с привязкой к данным, генерирующий минимальный SQL со встроенной блокировкой логических записей и преобразованием ошибок базы данных в события, в новом приложении - большая задача.
Вы также можете поэтапно выполнить переход, преобразовав код PowerBuilder во что-то, что может быть использовано приложением .NET. Как уже упоминалось, вы можете создавать COM-объекты с PB 10, который у вас есть, но для получения сборок придется перейти на 11.0 или 11.5. Значение этого может зависеть от того, насколько хорошо разделено ваше приложение. Если ваша бизнес-логика проходит через события и функции GUI, а не разделяется на невизуальные объекты (например, пользовательские классы), значение этого может быть сомнительным. Тем не менее, это дизайн faux pas , который, вероятно, следует исправить до полного преобразования в C #; это то, что можно сделать, сохраняя приложение PowerBuilder в качестве предварительного шага к поэтапному, а затем и к полному преобразованию.
Без сомнения, я бы предпочел, чтобы вы остались с PowerBuilder. Если это не удастся, я бы хотел, чтобы у вас все получилось. Просто помните, как только вы сделаете первый укус, вам придётся закончить его .
Удачи в поиске этого ремня,
Терри.
Я вижу, что вы упомянули о переносе "основных компонентов" в .NET для запуска. Как вы уже догадались, я думаю, что поэтапный подход - мудрое решение. Теперь определение «ядро» может быть спорным, но как насчет противоположной точки зрения. Пища для размышлений? (Очевидно, что это была неправильная неделя для начала диеты.) Исходя из того, где сейчас находится PB, было бы трудно разделить ваше приложение между PB и C # по функциональности приложения (например, счета к получению в PB, счета к оплате в C #). Подразделение, которое может работать, - это GUI против бизнес-логики. Как упоминалось ранее, выкачивание бизнес-логики из PB в исполняемые файлы C # уже возможно. Как насчет создания графического интерфейса в C #, когда DataWindows копируется из PB, а бизнес-логика откачивается как COM-объекты или сборки? Иначе говоря, для использования сборок .NET в PB вам придется либо перейти на уровень 11.x и перейти на Windows Forms, либо поместить их в COM-вызываемую оболочку .
.
Или просто обучите своих разработчиков на C # PowerBuilder. Это может быть просто слух, но я слышу, что новая маркетинговая линия PowerBuilder будет «настолько простой, что даже разработчик C # может использовать ее». ; -)