2008-10-16 3 views
6

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

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

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

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

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

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

+0

Подход RAD, то есть смешивание пользовательского интерфейса и логики, а также использование хранимых процедур делает миграцию сложной. Вы должны идентифицировать «швы», то есть часть кода, которую можно перенести и протестировать, и делать это постепенно. Взгляните на [Эффективно работающий с устаревшим кодом] (http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052). Стоит прочитать эту замечательную книгу. И переключитесь на SOA-подход, чтобы перенести свою бизнес-логику с пользовательского интерфейса и сохранить procs на серверы. – 2013-11-03 12:46:58

ответ

7

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

+0

Спасибо за ваши впечатления. Теперь бизнес решил отложить решение до нового года. Скорее всего, они перейдут на .NET3.5. Исходным решением .NET 2.0 было требование к установке фреймворка 90+ MB. – Ash 2008-10-18 04:46:16

+1

@Ash ... так что оставайтесь с Delphi и мигрируйте с помощью современных узоров. У вас есть много хороших фреймворков и компонентов, в чистом Delphi, для перехода на n-Tier, ORM, SOA или DDD. – 2013-11-03 12:51:59

3

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

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

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

+0

Спасибо, они стремятся полностью отойти от Delphi/Borland. Похоже, что поэтапный подход будет использоваться. – Ash 2008-10-18 04:48:19

0

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

9

Это звучит как really bad idea для меня.

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

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

+0

Бизнес видит отсутствие веб-разработки в Delphi в качестве основного риска. Они хотят платформу, которая позволяет им гибко выбирать разные уровни пользовательского интерфейса (Web, Desktop, Service и т. Д.). – Ash 2008-10-18 04:43:04

1

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

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

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

+0

Бизнес хочет полностью отойти от Borland/Codegear. Они также нуждаются в более гибких настройках пользовательского интерфейса, в Интернете, на рабочем столе, в мобильных устройствах (в этом порядке). – Ash 2008-10-18 04:53:04

8

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

Тематическое исследование после изучения конкретного случая показывает, что rewriting is a bad idea. (Наконечник шляпы kogus)

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

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

+0

Хорошие моменты и спасибо за ссылки. Полная переписывание - это, безусловно, последний вариант. С такой логикой в ​​базе данных, хотя многое из этого не нужно будет менять, по крайней мере, изначально. – Ash 2008-10-18 04:50:20

2

Переход от инструментов 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 (aka Windows Forms) и Windows Presentation Foundation (иначе WPF).

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

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

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

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

--jeroen

2

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

1

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

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

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