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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Пример из практики после примера показывает, что переписывание - плохая идея . (Шляпный наконечник до когус )

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

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

Answer 3

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

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

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

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

Также, скажите, пожалуйста, что вы на самом деле не покупали VS 2005. Вы можете купить лицензию MSDN Universal примерно за ту же цену и получить каждый продукт, связанный с разработкой Microsoft. Купите его у третьего лица, и вы получите хорошую скидку.

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

Answer 4

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

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

Просто мысль.

Answer 5

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

Answer 6

Отказ от инструментов 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 и пользовательский интерфейс полностью отличаются от 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 лет назад).

Удачи в выборе!

- Йерун

Answer 7

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

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

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

Answer 8

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

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

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

Answer 9

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