Миграция приложения Delphi 7 to.NET

любые советы о том, как перенести существующее бизнес-приложение Delphi 7 на .NET 2.0 в Visual Studio 2005?

Visual Studio 2005 уже приобретена, компания хочет отойти от инструментов Borland/Codegear.

приложение представляет собой один исполняемый файл клиентского сервера, используя ряд сторонних элементов управления UI и Crystal reports 10 для отчетности.

существует обширная бизнес-логика, распространенная по типам Delphi в пользовательском интерфейсе, а также столько же хранимых процедур SQL Server 2000. Другой целью является перемещение большей части хранимой логики proc в классы .NET.

чтобы уменьшить влияние на клиентов, предпочтительнее подход по частям, а не полная перезапись/преобразование, если это возможно. Спасибо заранее.

[Update] у кого-нибудь был опыт, хороший, плохой или уродливый, используя управляемый VCL для этого типа сценария?

6
.net delphi migration

9 ответов

Я работал в компании, которая переходила с Delphi на WPF/.Net Около 2007 года. Мы пробовали подход по частям. Это было больно. Мы всегда сталкивались с тонкими ошибками во взаимодействии. Вызов из Delphi в WPF или Winforms и обратно болезнен. Если различные элементы управления UI и окна вашего приложения много звонят друг другу, Я думаю, вы испытаете значительные растущие боли.

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

Я бы также предложил перейти в .Net 2008. Почему вы выбираете технологию, которой почти 4 года (против 2005 года)? Я думаю, что это очень, очень плохое бизнес-решение, чтобы перейти в .Net 2.0, Когда .Net 3.5 очень стабилен. Единственная веская причина, я бы никогда не представить руководство по .Объем 2.0 будет поддерживать Windows 2000. У вас еще есть клиенты? С Win2k? У вас все еще будут клиенты на Win2k к моменту завершения преобразования? У вас есть клиенты, которых вы не можете переместить в XP или Vista? .Net 3.0 и 3.5 не поддерживаются в Win2k. Это единственный недостаток, который я могу придумать.

.Net 3.5 и C# 2008 предлагают значительные преимущества для вашей компании. У вас есть ряд языковых функций, которые ускорят время разработки по сравнению с C# 2.0. У вас есть WPF, который значительно превосходит Winforms. Я бы сказал, что вы можете разработайте те же самые окна batteleship-gray, которые вы получите в Winforms с WPF, разработайте их быстрее, и когда вам понадобится глазная конфета, вы будете использовать технологию, которая может легко ее предоставить. Если вы изучаете новую оконную платформу для этого преобразования, почему бы не инвестировать в изучение нового материала?

кроме того, Пожалуйста, скажите мне, что вы на самом деле не купили VS 2005. Вы можете купить универсальный MSDN лицензия для около такой же цены, и получает каждый продукт развития родственный Корпорация Майкрософт не дает. Купите его у 3rd party, и вы получите хорошую скидку.

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

7

звучит как плохая идея для меня.

есть ли какое-либо технологическое преимущество для вашего продукта в .NET, или это в основном политическое решение быть магазином Microsoft? Для клиент-сервера Delphi довольно сложно победить. Я использовал VS2005 / 8, и это действительно и действительно искренне и искренне не так хорошо, как Delphi для разработки Win32. Но если вы собираетесь мигрировать в интернет по дороге, то VS имеет определенные преимущества.

Если упрямые деловые люди просто отказываются использовать Delphi больше, тогда KiwiBastard прав, IMO. Преобразовать сначала в Delphi.NET, затем мигрируйте оттуда в VS2005. Или 2010, так как это более реалистичная временная шкала :)

9

ранее я работал в компании, которая хотела конвертировать из Delphi в C#.NET потому что .NET-это все прохладный и блестящий. Они привлекли еще несколько разработчиков, у которых было много опыта C#, и в итоге разработчикам потребовалось в 3 раза больше времени, чтобы перенести приложение на C#, а затем написать его в первый раз в Delphi для очень небольшого дополнительного ROI (в процессе было добавлено несколько новых функций). Кроме того, клиенты не были довольны производительностью приложения или пользовательский интерфейс.

тематическое исследование после тематического исследования показывает, что переписывание-плохая идея. (Наконечник шляпы к kogus)

Если вы должны перейти на .NET (да, я знаю, вы не приняли решение, кто-то с меньше информации сделал), то я бы предложил использовать Delphi для .NET или Файлом Remobjects Oxygene По. Последний является подключаемым модулем Visual Studio. Но даже Марк Хофман, главный архитектор программного обеспечения RemObjects Оксиген сказал, что это плохая идея перенести отлично работающее приложение на .NET " только потому, что."

Если вы можете подождать Delphi Prism, который также является надстройкой Visual Studio и, как ожидается, выйдет в конце этого года.

8

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

Если вы можете, это может быть проще преобразовать приложение в Delphi.NET во-первых, тогда, по крайней мере, биты .NET смогут общаться немного проще.

просто мысли.

3

переход от инструментов CodeGear / Borland в основном устраняет любое решение на основе Delphi .NET и полную перезапись вашего приложения.

Я надеюсь, что мой ответ ниже поможет с вашими решениями.

из опыта (переписав приложение Delphi с командой людей) это сводится к одному из двух вариантов ниже.

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

в нашем случае эти усилия были оправданы, так как старое приложение Delphi (которое на самом деле было Kylix) имело конец жизни по разным причинам. Наша перепись состояла из двух частей: переписывание с ограниченной дополнительной функциональностью, за которой следовало много дополнительной функциональности (дизайн первой части уже учитывал вторую часть).

вернемся к вашему выбору:

1-полная перезапись на C# или VB.NET в Visual Studio

2- частичное повторное использование существующего кода бизнес-уровня Delphi с помощью Oxygene из RemObjecs (плагин Visual Studio с синтаксисом, очень похожим на синтаксис Delphi). CodeGear вскоре предложит Prism (вероятно, до конца 2008 года), который также будет интегрирован в Visual Studio.

поскольку .NET Data access и UI полностью отличаются от Delphi, вам придется делать это с нуля (как для сценария 1, так и для сценария 2). Visual Studio 2008 предлагает множество преимуществ по сравнению с Visual Studio 2005.

нет такой вещи, как делать эту миграцию постепенно, так как вы делаете полное изменение платформы здесь, это подход "все или ничего".

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

Visual Studio может взаимодействовать с Crystal Reports и хорошо сочетается с SQL Server.

Так как Visual Studio 2008 предлагает много из преимуществ (не только .NET 3.5, но и производительность), вам лучше пойти с этим. На стороне пользовательского интерфейса необходимо сделать сбалансированный выбор между WinForms (он же Windows Forms) и Windows Presentation Foundation (он же WPF).

Если это переписывание от 1 до 1, Вы можете придерживаться WinForms, поскольку он знаком с тем, что у вас есть. Вероятно, вам нужно использовать некоторые сторонние компоненты, чтобы получить ваш пользовательский интерфейс; DevExpress-хороший выбор здесь, поскольку у них есть аналогичные компоненты в Delphi и Visual Studio.

но если вы хотите пойти на будущее глаз конфеты, то вы можете рассмотреть WPF. Будьте готовы к более крутой кривой обучения здесь, чем WinForms, поскольку она сильно отличается от того, к чему вы привыкли.

Если вы решите остаться с Delphi, вы можете посмотреть в VCL для Интернета (он же IntraWeb) и в Delphi 2009 (многое изменилось в мире Delphi с тех пор, как Delphi 7 был объявлен 6 лет назад).

удачи ваш выбор!

--jeroen

2

Я бы предложил посмотреть на Гидру из RemObjects. Он в основном стучит COM-интерфейс для вас и предоставляет шаблон наблюдателя для взаимодействия между вашим приложением Delphi и .Net. Формы .Net могут отображаться на панелях внутри приложения Delphi. Это обеспечивает хороший путь миграции, где вы заменяете свой код Delphi бит за битом при переносе функциональности .Сеть.

2

для меня вопрос будет такой: какой язык вы используете? Я надеюсь, что C# , а не VB.Net - ... (При всей неудобной политике в этом usecase это не ясно ни в коем случае.)

следующий вы, вероятно, услышите, что есть конвертеры, которые помогут вам сделать это. Мы только что прошли оценку таких конвертеров (Delphi 7 на C#) и были очень! разочарованный.

могу я предложить компромисс? Как насчет Delphi Prism? Это Delphi в VS2008. Конечно, у вас все еще есть Delphi и, следовательно, Codegear, но у вас также есть VS (как ожидает ваша компания).

1

был научный отчет об успешном преобразовании 1,5-миллионного линейного проекта Delphi В C# Джоном Брантом, Доном Робертсом и др. Он написал синтаксический анализатор Delphi, генератор C# и множество правил преобразования на AST. Постепенно расширяя набор правил, делая ежедневную сборку, множество модульных тестов и некоторые переписывания сложных частей Delphi позволили ему с командой из 4, среди которых некоторые из оригинальных разработчиков, с глубокими знаниями Delphi & C#, перенести программное обеспечение в 18 месяцев. John Brant & Don Roberts будучи оригинальными разработчиками браузера рефакторинга и конструктора компилятора SmaCC, вы вряд ли сможете идти так быстро.

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

авторы сделали крупномасштабные рефакторинги, оставаясь на одной платформе для другого проекта, полностью заменив инфраструктуру персистентности. Это может иметь отношение к старшим (BDE?) базовый проект.

1

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

0