Перенос приложения PowerBuilder в .NET

Ответ 1

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

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

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

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

Если вы просто хотите развернуть Windows Forms, Web Forms, Assemblies или .NET веб-службы или использовать библиотеки .NET, то, как сказал Павел, переход на 11.0 или 11.5 может привести вас туда, миграция. (Я бы предложил снова рассмотреть и убедиться, что у вас хороший дизайн для новой платформы, особенно с помощью Web Forms, но эти усилия должны быть значительно меньше, чем переписывать.) Если вы хотите развернуть приложение WPF, я знаю год довольно долго ждать, но изучение PowerBuilder 12 может стоить усилий. Сработало правильно, возможности WPF могут поставить PowerBuilder в уникальную и мощную позицию.

Если переписывание гарантировано в вашем будущем (ливни выглядят дешевле), вы можете захотеть фазировать преобразование. DataWindow.NET позволяет вам взять с собой свои DataWindows. (Моя любимая теория недели заключается в том, что разработчики PowerBuilder воспринимают DataWindow как нечто само собой разумеющееся, пока не будут воспроизведены все функциональные возможности, которые встроены.) Возможность отбросить ранее существовавшие, предварительно протестированные, многострочные, прокручиваемые, минимальные ресурсопотребляющий, печатный, динамический пользовательский интерфейс с привязкой к данным, генерирующий минимальный SQL со встроенной блокировкой логической записи и преобразованием ошибок базы данных в события, в новое приложение - большая нога.

Вы также можете выполнить фазу перехода, преобразов свой код PowerBuilder в то, что потребляется .NET-приложением. Как уже упоминалось, вы можете создавать COM-объекты с PB 10, которые у вас есть, но вам придется перейти на 11.0 или 11.5 для сборки сборок. Значение этого может зависеть от того, насколько хорошо разбито ваше приложение. Если ваша бизнес-логика змеивается через события и функции графического интерфейса пользователя, а не разбивается на не визуальные объекты (так называемые пользовательские классы), ценность этого может быть сомнительной. Тем не менее, это проект faux pas, который, вероятно, должен быть исправлен до полного преобразования в С#; это то, что можно сделать, сохраняя при этом приложение PowerBuilder в качестве предварительного шага поэтапного, а затем полного преобразования.

Без сомнения, я предпочел бы, чтобы вы остались с PowerBuilder. В противном случае я хотел бы, чтобы вы преуспели. Просто помните, как только вы возьмете этот первый укус, вам нужно будет закончить его.

Удачи найти этот пояс,

Терри.

Я вижу, что вы упомянули о переносе "основных компонентов" на .NET для запуска. Как вы уже догадались, я считаю, что поэтапный подход - это мудрое решение. Теперь определение "ядро" может быть спорным, но как насчет противоположной точки зрения. Пища для размышлений? (Очевидно, что это была неправильная неделя, чтобы начать диету.) Основываясь на том, где сейчас находится PB, было бы трудно разделить ваше приложение между PB и С# по функциональности приложения (например, дебиторская задолженность в PB, кредиторская задолженность на С#). Разделение, которое может работать, - это графический интерфейс и бизнес-логика. Как уже упоминалось, перекачка бизнес-логики из PB в исполняемые файлы, которые С# может использовать, уже возможна. Как насчет создания GUI на С#, с DataWindows, скопированным из PB, и бизнес-логикой, откачиваемой как COM-объекты или сборки? Идя в другую сторону, чтобы потреблять сборки .NET в PB, вам придется либо перейти на 11.x, либо перенестись в Windows Forms, либо поместить их в COM-обертка.

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

Ответ 2

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Я бы вернулся к этой теории. Я предпринял попытку конверсии из PB8 в Java в проекте несколько лет назад, который потерпел неудачу, даже с использованием первого поколения HTML DataWindow. Мой нынешний работодатель изо всех сил движется на С#, не используя Datawindow.NET, несмотря нa > 2K DWO в нашем текущем продукте. Я не ожидаю того дня, когда начнется реализация. (Весь продукт состоит из нескольких пользовательских приложений, более десятка сервисов и использует около 70 PBD).

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

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

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

Ответ 7

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

Ответ 8

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

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