Портирование приложения PowerBuilder в.NET
У кого-нибудь есть советы по переносу бизнес-приложения PowerBuilder 10 на.NET?
Моя компания рассматривает вопрос о переносе унаследованного PB-приложения на.NET (C#), и мне просто интересно, есть ли у кого-нибудь опыт - хороший или плохой - которым вы бы хотели поделиться.
Приложение довольно большое с 10 библиотеками PBL, некоторыми PFC, а также пользовательскими инфраструктурами. Также выполняется большое количество вызовов DLL. Наконец, он использует базу данных Microsoft SQL Server.
Мы обсудили портирование "основного" кода приложения на.NET, а затем перенесли более расширенную функциональность по мере необходимости.
9 ответов
Когда я увидел название, я просто собирался скрыться, будучи известным фанатом PB. Ну что ж. Спасибо за вотум доверия, Бернард.
Моим первым предложением было бы отказаться от языка самообмана. Если я съем половину "облегченного" чизкейка, я все равно потеряю свой пояс. Миграция может занять всего 10 минут. То, что вы будете делать, это переписать. Время нужно измерять как переписанное. Риск должен быть измерен как переписать. И дизайнерские усилия должны быть измерены как переписать.
Да, я сказал дизайн усилий. "Миграция" вызывает в воображении образы прокачки кода через какой-то черный ящик с переводом, отражающим оригинал, выходящий с другой стороны. Вы хотите повторить те же ошибки дизайна, которые были допущены в 1994 году, с которыми вы жили годами? Даже с кодом отличного качества, я предполагаю, что отличный выбор дизайна в PowerBuilder может быть ужасным выбором дизайна в C#. Пропускает ли прямое преобразование мощь и сильные стороны платформы? Будете ли вы жить с последствиями пренебрежения хорошим дизайном C# в течение следующих 15 лет?
Не обращайте внимания на это, поскольку вы не упоминаете свою мотивацию для перехода "на.NET", трудно предположить, какие варианты у вас могут быть, чтобы уменьшить риск переписывания. Если ваше руководство просто решило, что разработчики PowerBuilder плохо пахнут и должны быть удалены из офиса, тогда удачи в переписывании.
Если вы просто хотите развернуть Windows Forms, Web 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, а не разделяется на невизуальные объекты (например, пользовательские классы), значение этого может быть сомнительным. Тем не менее, это ошибка проекта, которую, вероятно, следует исправить перед полным преобразованием в 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# может использовать ее".;-)
Я думаю, что gbjbaanb дал вам хороший ответ выше.
Некоторые другие вопросы, которые стоит рассмотреть:
- Является ли это приложение PB10 новым, хорошо написанным приложением PB10, или оно было создано в 1998 году в PB4, а затем постепенно преобразовано в PB10 за эти годы? Хорошо написанное приложение должно иметь приличное разделение между бизнес-логикой и графическим интерфейсом, и вы сможете систематически переносить свой код на.Net. По крайней мере, это должно быть намного проще, чем если бы это было унаследованное приложение PB, и в этом случае вполне вероятно, что в кнопках, окнах данных, меню, а также кто знает, что еще будет захоронено множество логики. Не невозможно, но сложнее переделать.
- Насколько хорошо работает приложение? Если все в порядке и стабильно, и не требует много новых функций, то, возможно, не нужно переписывать. Или, как сказал gbjbaanb, вы можете обернуть.Net-обертки вокруг некоторых частей, а затем предоставить необходимую вам функциональность без полного переписывания. Если, с другой стороны, ваше приложение является опасным, неприятным, не совсем удовлетворяющим бизнес-потребностям и делает ваших пользователей неэффективными, тогда у вас может быть необходимость переписать или, возможно, провести серьезный рефакторинг, а затем внести некоторые улучшения. Есть ребята из ПБ, отбывающие наказание, я имею в виду, зарабатывая на жизнь вторым сценарием.
Я не против переписывания, если программное обеспечение очень плохое и негативно влияет на бизнес компании, но даже тогда постепенные корректировки и улучшения являются менее рискованным способом для развития системы.
Кроме того, не оставляйте залог в этой теме до тех пор, пока не появятся сообщения Терри Вота. Он на Stackru и является одним из лучших ребят из PB.
Если он довольно большой, вы могли бы получить лучшие результаты, написав для него внешний интерфейс в.net (или через веб-интерфейс) и используя его для взаимодействия с кодом PB, предполагая, что вы можете представить его функциональность в виде API.
Если вы используете PB 9 или выше, вы можете генерировать COM или.NET библиотеки, которые затем можно использовать с помощью C# GUI. Я бы рекомендовал это переписать на любом новом языке.
Помните, что переписывание никогда не является серебряной пулей, оно всегда оказывается более трудоемким, сложным и ошибочным, чем вы ожидаете.
Я думаю, что любой, рассматривающий это для большого приложения, был бы довольно сумасшедшим, если бы не очень серьезно подумал об использовании DataWindow.NET, чтобы не потерять свои инвестиции в DW.
Моя любимая теория недели заключается в том, что разработчики PowerBuilder принимают DataWindow как должное до тех пор, пока им не придется воспроизводить все встроенные функции.
Я бы поддержал эту теорию. Несколько лет назад я предпринял попытку преобразования из PB8 в Java в проекте, который с треском провалился, даже с использованием HTML-окна первого поколения HTML. Мой нынешний работодатель одержим желанием перейти на C#, не используя Datawindow.NET, несмотря на> 2K DWO в нашем текущем продукте. Я не с нетерпением жду того дня, когда начнется реализация. (Весь продукт состоит из нескольких пользовательских приложений, более десятка сервисов и использует около 70 PBD)
OP - если ваше приложение необычно хорошо структурировано (возможно, изначально написано для EA Server?), Это не будет порт. В средах PB & .NET все работает по-разному, чтобы обычный порт работал удовлетворительно. Я не могу подчеркнуть это достаточно - если вы действительно используете модель событий PB, "порт", скорее всего, будет неудачей.
Вам нужно взглянуть на логический поток (взаимосвязанный пользовательский интерфейс и процесс), поток управления (которому сейчас принадлежит процесс или данные), доступ к данным (пользовательский интерфейс, уровень данных,??) и части используемой модели событий DW, которые вы используете. из кода. Если вы думаете о ASP.NET (как мы), весь ваш опыт взаимодействия с пользователем должен будет измениться, и это отразится на других соображениях.
Не связанная напрямую с кодом, автоматизация сборки изменится (мы используем PowerGen для согласованных сборок PB; MSBuild сильно отличается), как и ваша установка и настройка.
Я не знаю, хорошо это или нет, но проверь этот (коммерческий) продукт: PB.Net
PHB в крупных корпорациях считают, что Powerbuilder - это игрушечный язык, и переход на новый язык, такой как C#, тривиален и может быть осуществлен с небольшими затратами. Фактически, перенос приложения PB на любой другой язык будет стоить как минимум столько же, сколько разработка совершенно нового приложения на новом языке. Получающееся приложение, как правило, теряет функциональность по сравнению с оригиналом и приводит к неудовлетворенности пользователя. Я видел несколько попыток - все провалились из-за сложности и проблем пользователя.
Если это не сломано, не исправляйте это.
Возможно, вы захотите потратить некоторое время на изучение PowerBuilder 11.5 (недавно выпущенный), который добавляет значительную интеграцию.NET.
Переход на PowerBuilder 11.5 для использования нового кода.NET, безусловно, будет намного проще, чем полное переписывание всего приложения на C#.
Да, это выполнимо сейчас без переписывания периода сервисных компонентов.
PB 12.5>
И целевой миграции и интеграции компонентов служб и интеграции в C#.
Стратегия миграции / интеграции может варьироваться в зависимости от масштаба вашего проекта, масштабируемости, ресурсов и сроков.
Вы можете использовать эти типы целей и проектов в PowerBuilder .NET. Перейдите по этой ссылке Sybase_PB .Net
- Приложение окна WPF Приложение окна WPF, клиентский прокси WCF или клиентский прокси REST
- PB Assembly Клиентский прокси WCF, REST Client Proxy или PB Assembly
- .NET Assembly Клиентский прокси WCF, REST Client Proxy или.NET Assembly
- Сервис WCF Клиентский прокси WCF, Клиентский прокси REST или Сервис WCF