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

Я работал в компании, которая переходила с 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.

Мне это кажется действительно плохой идеей.

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

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

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

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

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

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

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

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

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

Отказ от инструментов 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).

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

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

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

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

- Джерун

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

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

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

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

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

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

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

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