Портирование приложений с помощью инструментария powerbuilder to.NET

есть ли у кого-нибудь советы по миграции бизнес-приложения PowerBuilder 10 в .NET?

моя компания рассматривает возможность переноса устаревшего приложения PB в .NET (C#), и мне просто интересно, есть ли у кого - нибудь опыт - хороший или плохой-которым вы хотели бы поделиться.

приложение довольно большое с 10 библиотеками PBL, некоторыми PFC, а также пользовательскими фреймворками. Существует большое количество вызовов DLL, а также. Наконец, он использует Microsoft SQL База данных сервера.

мы обсудили перенос" основного " кода приложения в .NET, а затем перенос более расширенных функций по мере необходимости.

15
.net c# migration powerbuilder powerbuilder-conversion

9 ответов

когда я увидел название, я просто собирался скрываться, будучи известным фанатиком PB. Ну что ж. Спасибо за вотум доверия, Бернард.

моим первым предложением было бы отказаться от языка самообмана. Если я съем половину "облегченного" чизкейка, я все равно потеряю из виду свой пояс. Миграция может занять всего 10 минут. Что вы будете делать-это переписать. The времени необходимо измерить как переписать. The риск должен быть измеряется как переписывание. И дизайн должно быть измерено как переписывание.

Да, я сказал конструкторских работ. "Migrate" вызывает образы перекачивания кода через какой-то черный ящик с переводом, отражающим оригинал, выходящий с другой стороны. Вы хотите повторить те же ошибки дизайна, которые были сделаны еще в 1994 году, что ты был живет с годами? Даже с отличным качеством кода, я бы предположил, что отличный выбор дизайна в PowerBuilder может быть ужасным выбором дизайна в C#. Разве прямое преобразование пренебрегает мощью и силой платформы? Будете ли вы живет с последствия пренебрежения хорошим дизайном C# в течение следующих 15 лет?

эта тирада в сторону, так как вы не упоминаете свою мотивацию для перехода "на .NET", трудно предположить, какие варианты у вас могут быть, чтобы уменьшить риск перезаписи. Если ваше руководство просто решило, что разработчики PowerBuilder пахнут плохо и нужно вычеркнуть из офиса, тогда удачи на переписывании.

Если вы просто хотите развернуть Windows Forms, веб-формы, сборки или веб-службы .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#, уже возможна. Как насчет создания GUI в C#, с окнами данных, скопированными из PB, и бизнес-логикой, откачанной как COM-объекты или сборки? В противном случае, чтобы использовать .NET-сборки в PB, вам придется либо перейти на 11.x и перенести в Windows Forms или поместить их в COM вызываемая обертка.

или просто обучите своих разработчиков C# С помощью инструментария powerbuilder. Это может быть просто слух, но я слышал, что новая маркетинговая строка PowerBuilder будет "настолько простой, что даже разработчик C# может ее использовать.";-)

22

Я думаю, gbjbaanb дал вам хороший ответ выше.

некоторые другие вопросы, которые стоит рассмотреть:

  • является ли это приложение PB10 новым, хорошо написанным приложением PB10, или оно было сделано в 1998 году в PB4, а затем постепенно преобразовано в PB10 на протяжении многих лет? Хорошо написанное приложение должно иметь приличное разделение между бизнес-логикой и GUI, и вы должны иметь возможность систематически переносить свой код .Сеть. По крайней мере, это должно быть намного проще, чем если бы это был устаревший PB app, в этом случае было бы вероятно, что у вас будет тонны логики, похороненной в кнопках, окнах данных, меню и кто знает, что еще. Не невозможно, но труднее переделать.
  • насколько хорошо работает приложение? Если он в порядке и стабилен, и не требует много новых функций, то, возможно, он не нуждается в переписывании. Или, как сказал gbjbaanb, вы можете поместить .Net-обертки вокруг некоторых частей, а затем предоставить необходимую функциональность без полной перезаписи. Если, с другой стороны, ваше приложение сварливый, противный, не очень удовлетворяющий бизнес-потребности, и делает ваших пользователей неэффективными, тогда у вас может быть случай для переписывания или, возможно, серьезного рефакторинга, а затем некоторых улучшений. Есть парни из ПБ, отбывающие наказание, я имею в виду, зарабатывающие на жизнь по второму сценарию.

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

кроме того, не бросайте эту тему до тех пор, пока Терри вот не опубликует. Он на StackOverflow и является одним из лучших парней PB.

6

Если он довольно большой, у вас могут быть лучшие результаты, написав интерфейс для него в .net (или веб-GUI) и используя его для взаимодействия с вашим кодом PB, предполагая, что вы можете выставить функциональность как API.

Если вы используете PB 9 или выше, вы можете генерировать com или .NET DLL, который вы можете использовать с помощью C# GUI. Я бы рекомендовал это переписать на любом новом языке.

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

4

возможно, вы захотите провести некоторое время, исследуя PowerBuilder 11.5 (недавно выпущенный), который добавляет некоторую значительную интеграцию .NET.

миграция в PowerBuilder 11.5 для использования нового кода .NET, безусловно, будет намного проще, чем полностью переписать все приложение на C#.

3

Я не знаю, хорошо это или нет, но проверьте этот (коммерческий) продукт:PB.Net

3

моя любимая теория недели заключается в том, что разработчики PowerBuilder принимают DataWindow как должное, пока им не придется воспроизводить всю функциональность, которая встроена.

Я бы поддержал эту теорию. Несколько лет назад я попытался преобразовать PB8 в Java в проекте, который потерпел неудачу, даже используя HTML-окно данных первого поколения. Мой нынешний работодатель одержим переходом на C#, а не использованием Datawindow.NET несмотря на > 2K DWOs в нашем текущем продукте. Я не с нетерпением жду того дня, когда придет осознание. (весь продукт состоит из нескольких пользовательских приложений, более десятка сервисов и использует около 70 Пбд)

OP-если ваше приложение не необычно хорошо структурировано (возможно, изначально написано для EA Server?), это не будет порт. Вещи работают слишком по-разному в средах PB & .NET для простого порта, чтобы работать удовлетворительно. Я не могу подчеркнуть это достаточно - если вы действительно используя модель событий PB, "порт", вероятно, будет сбоем.

вам нужно посмотреть на логический поток (переплетенный UI & process), поток управления (Кто владеет процессом или данными прямо сейчас), доступ к данным (UI, слой данных,??) и части модели событий DW, которые вы используете из кода. Если ты думаешь о ... ASP.NET (как и мы), весь ваш опыт взаимодействия с пользователем должен будет измениться, и это будет возвращаться к другим соображениям.

не напрямую связанный с кодом, автоматизация сборки изменится (мы используем PowerGen для последовательных сборок PB; MSBuild очень отличается), как и ваша установка и настройка.

3

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

3

PHB в крупных корпорациях считают, что Powerbuilder-это игрушечный язык, и переход на новый язык, такой как C#, тривиален и может быть сделан по низкой цене. Фактически, перенос приложения PB на любой другой язык будет стоить по крайней мере столько же, сколько разработка совершенно нового приложения на новом языке. В результате приложение, как правило, теряет функциональность по сравнению с оригиналом и приведет к неудовлетворенности пользователей. Я видел несколько попыток - все они потерпели неудачу из-за трудности и проблемы пользователей.

Если он не сломан, не исправляйте его.

3

Да, теперь это выполнимо без периода перезаписи компонентов службы.

PB 12.5>

и целевые миграции и интеграции компонентов GUI и службы в c#.

стратегия миграции/интеграции может варьироваться в зависимости от области проекта, масштабируемости, ресурсов и временной шкалы.

вы можете использовать эти целевые и проектные типы В PowerBuilder .Сеть. Обратитесь по этой ссылке Sybase_pb .Net

  • приложение окна WPF Приложение окна WPF, прокси-сервер клиента WCF или прокси-сервер клиента REST
  • PB Assembly WCF Client Proxy, rest Client Proxy или PB Assembly
  • .Net-сборки клиента WCF прокси-сервер, REST-клиента прокси-сервера, или .Net-сборки
  • службы WCF WCF-клиента прокси-сервера, остальные Прокси клиента или службы WCF
0