Портирование приложения PowerBuilder к.NET
На самом деле вы можете сделать это в C ++ 98. Нет необходимости в новом стандарте. Вы не размещаете delete внутри f. Вместо этого просто создайте объект, который вы передаете в f с помощью auto_ptr guard:
Test *obj = new Test();
f(auto_ptr<Test>(new Test()).get());
f(obj);
Автоматический указатель обеспечит освобождение объекта после завершения выполнения функции.
Ну, если честно, это * почти то же самое. Если вам явно нужно удалить указатель внутри f, а не просто охранять его, чтобы убедиться, что он освобожден, тогда вам действительно нужен умный указатель, а не просто auto_ptr, для этого вам нужно либо использовать boost или c ++ 11, либо просто написать себя, это действительно не сложно реализовать.
Также обратите внимание, что auto_ptr устарела в новом стандарте, так что этот код не совместим напрямую.
8 ответов
Когда я увидел название, я просто собирался скрыться, будучи известным фанатом PB. Ну что ж. Спасибо за вотум доверия, Бернард.
Моим первым предложением было бы отказаться от языка самообмана. Если я съем половину "облегченного" чизкейка, я все равно потеряю свой пояс. Миграция может занять всего 10 минут. То, что вы будете делать, это переписать . Время должно быть измерено как перезапись. Риск необходимо измерять как переписанный. И проектное усилие должно быть измерено как переписанное.
Да, я сказал дизайн усилий. «Миграция» вызывает в воображении образы прокачки кода через какой-то черный ящик с переводом, отражающим оригинал, выходящий с другой стороны. Вы хотите повторить те же ошибки дизайна, которые были допущены в 1994 году, когда вы жили с в течение многих лет? Даже с кодом отличного качества, я предполагаю, что отличный выбор дизайна в PowerBuilder может быть ужасным выбором дизайна в C #. Пропускает ли прямое преобразование мощь и сильные стороны платформы? Будете ли вы жить с последствиями пренебрежения хорошим дизайном C # в течение следующих 15 лет?
Этот разглагольствования в сторону, так как вы не упоминаете свою мотивацию для перехода "к .NET, «трудно предположить, какие варианты у вас могут быть, чтобы снизить риск переписывания. Если ваше руководство просто решило, что разработчики PowerBuilder плохо пахнут и должны быть удалены из офиса, тогда удачи в переписывании.
Если вы просто хотите развернуть веб-службы Windows Forms, Web Forms, Assemblies или .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 # может использовать ее». ; -)
Возможно, вы захотите потратить некоторое время на изучение PowerBuilder 11.5 (недавно выпущенный), который добавляет значительную интеграцию .NET.
Миграция в PowerBuilder 11.5 для использования нового кода .NET, безусловно, будет намного проще, чем полное переписывание всего приложения на C #.
Я не знаю, хорошо это или нет, но проверьте этот (коммерческий) продукт: PB.Net
Моя любимая теория недели заключается в том, что разработчики PowerBuilder принимают DataWindow как должное, пока им не придется воспроизводить все встроенные функции.
Я бы поддержал эту теорию. Несколько лет назад я предпринял попытку преобразования из PB8 в Java в проекте, который с треском провалился, даже с использованием HTML-окна первого поколения HTML. Мой нынешний работодатель одержим желанием перейти на C #, не используя Datawindow.NET, несмотря на> 2K DWO в нашем текущем продукте. Я не с нетерпением жду того дня, когда начнется реализация. (Весь продукт состоит из нескольких пользовательских приложений, более десятка сервисов и использует около 70 PBD)
OP - если ваше приложение не является необычным хорошо структурированный (возможно, изначально написанный для EA Server?), это не будет порт. В PB & A все работает по-другому Среды .NET для простого порта для удовлетворительной работы. Я не могу подчеркнуть это достаточно - если вы действительно используете модель событий PB, «порт», скорее всего, будет неудачей.
Вам необходимо взглянуть на логический поток (переплетенный пользовательский интерфейс и процесс), поток управления (которому принадлежит процесс или данные прямо сейчас ), доступ к данным (пользовательский интерфейс, уровень данных, ?? ) и части модели событий DW, которые вы используете из кода. Если вы думаете о ASP.NET (как и мы), весь ваш опыт взаимодействия с пользователем должен будет измениться, и это отразится на других соображениях.
Не связанная напрямую с кодом, автоматизация сборки изменится (мы используем PowerGen для согласованных сборок PB; MSBuild сильно отличается), как и ваша установка & amp; установка.
PHB в крупных корпорациях считают, что Powerbuilder - это игрушечный язык, и переход на новый язык, такой как C #, тривиален и может быть осуществлен при низких затратах. Фактически, перенос приложения PB на любой другой язык будет стоить как минимум столько же, сколько разработка совершенно нового приложения на новом языке. Получающееся приложение обычно теряет функциональность по сравнению с оригиналом и приводит к неудовлетворенности пользователя. Я видел несколько попыток - все потерпели неудачу из-за сложности и проблем пользователя.
Если он не сломан, не чините его.
Если он довольно большой, вы могли бы получить лучшие результаты, написав для него внешний интерфейс в .net (или через графический интерфейс на основе веб-интерфейса) и используя его для взаимодействия с кодом PB, предполагая, что вы может предоставлять функциональность как API.
Если вы используете PB 9 или выше, вы можете генерировать библиотеки COM или .NET , которые затем можно использовать с помощью графического интерфейса C #. Я бы порекомендовал это вместо переписывания на любом новом языке.
Помните, что переписывание никогда не бывает серебряной пулей, оно всегда оказывается более трудоемким, сложным и ошибочным, чем вы ожидаете.
Я думаю, что gbjbaanb дал вам хороший ответ выше.
Некоторые другие вопросы, заслуживающие рассмотрения:
- Является ли это приложение PB10 новым, хорошо написанным приложением PB10 или оно было создано в 1998 году в PB4, а затем постепенно преобразовывалось в PB10 на протяжении многих лет? Хорошо написанное приложение должно иметь приличное разделение между бизнес-логикой и графическим интерфейсом, и вы сможете систематически переносить свой код на .Net. По крайней мере, это должно быть намного проще, чем если бы это было устаревшее приложение PB, и в этом случае вполне вероятно, что у вас будут тонны логики в кнопках, окнах данных, меню и кто знает, что еще. Не невозможно, но труднее переработать.
- Насколько хорошо работает приложение? Если все в порядке и стабильно, и не требует много новых функций, то, возможно, его не нужно переписывать. Или, как сказал gbjbaanb, вы можете поставить. Чистые обертки вокруг некоторых частей, а затем раскрывают нужную вам функциональность без полного переписывания. Если, с другой стороны, ваше приложение является странным, неприятным, не совсем удовлетворяющим бизнес-потребностям и делает ваших пользователей неэффективными, то у вас может быть необходимость переписать или, возможно, провести серьезный рефакторинг, а затем внести некоторые улучшения. Есть ребята из ПБ, отбывающие наказание, я имею в виду, зарабатывая на жизнь вторым сценарием.
Я не против переписывания, если программное обеспечение чрезвычайно плохое и негативно влияет на бизнес компании, но даже тогда постепенные корректировки и улучшения являются менее рискованным способом для развития системы.
Кроме того, не оставляйте залог в этой ветке до тех пор, пока не будет опубликован пост Терри Вота. Он на StackOverflow и один из лучших ребят из PB.
не совсем удовлетворяющих бизнес-потребности и делающих ваших пользователей неэффективными, тогда у вас может быть необходимость переписать или, возможно, какой-то серьезный рефакторинг, а затем некоторые улучшения. Есть ребята из ПБ, отбывающие наказание, я имею в виду, зарабатывая на жизнь вторым сценарием.Я не против переписывания, если программное обеспечение чрезвычайно плохое и негативно влияет на бизнес компании, но даже тогда постепенные корректировки и улучшения являются менее рискованным способом для развития системы.
Кроме того, не оставляйте залог в этой ветке до тех пор, пока не будет опубликован пост Терри Вота. Он на StackOverflow и один из лучших ребят из PB.
не совсем удовлетворяющих бизнес-потребности и делающих ваших пользователей неэффективными, тогда у вас может быть необходимость переписать или, возможно, какой-то серьезный рефакторинг, а затем некоторые улучшения. Есть ребята из ПБ, отбывающие наказание, я имею в виду, зарабатывая на жизнь вторым сценарием.Я не против переписывания, если программное обеспечение чрезвычайно плохое и негативно влияет на бизнес компании, но даже тогда постепенные корректировки и улучшения являются менее рискованным способом для развития системы.
Кроме того, не оставляйте залог в этой ветке до тех пор, пока не будет опубликован пост Терри Вота. Он на StackOverflow и один из лучших ребят из PB.
Я имею в виду зарабатывать на жизнь вторым сценарием.Я не против переписывания, если программное обеспечение чрезвычайно плохое и негативно влияет на бизнес компании, но даже тогда постепенные корректировки и улучшения являются менее рискованным способом для развития системы.
Кроме того, не оставляйте залог в этой ветке до тех пор, пока не будет опубликован пост Терри Вота. Он на StackOverflow и один из лучших ребят из PB.
Я имею в виду зарабатывать на жизнь вторым сценарием.Я не против переписывания, если программное обеспечение чрезвычайно плохое и негативно влияет на бизнес компании, но даже тогда постепенные корректировки и улучшения являются менее рискованным способом для развития системы.
Кроме того, не оставляйте залог в этой ветке до тех пор, пока не будет опубликован пост Терри Вота. Он на StackOverflow и один из лучших ребят из PB.
Я думаю, что любой, кто рассматривает это для большого приложения, был бы довольно сумасшедшим, если бы не очень серьезно подумал об использовании DataWindow.NET, так как чтобы не потерять свои инвестиции в DW.