Перенос приложения из Delphi в Silverlight C # - PullRequest
3 голосов
/ 11 апреля 2011

У меня есть устаревшее приложение для учета рабочего стола, разработанное с использованием Delphi 5 & Paradox, которое я собираюсь перевести на веб-приложение Silverlight (ради UX) с SQL Server.реализовать это быстро?

Я знаю, что это очень открытый вопрос, и я не ищу конкретных ответов.Вместо этого мнение / опыт от пользователей SO.

Моя основная проблема связана с миграционным подходом, возможной архитектурой и шаблонами проектирования (для SL, я знаю, MVVM).

Ответы [ 3 ]

1 голос
/ 23 апреля 2011

Если ваша бизнес-логика хорошо отделена от пользовательского интерфейса, вы можете начать с «переноса» своего кода на Delphi Prism, а не на C #. Это предлагает более короткий путь миграции. Если ваша бизнес-логика тесно связана с пользовательским интерфейсом (как это часто случалось 10-15 лет назад), то лучше было бы переписать все с нуля.

И как только у вас есть весь код в Pascal и работает, переписать его на C # (если он вам нужен в конце) почти тривиально с помощью декомпилятора.

1 голос
/ 23 апреля 2011

Быстро?Это то, что хочет каждый менеджер, но я сомневаюсь в этом.

У вас есть принципиально разные модели пользовательского интерфейса и разные языки программирования.Если эти приложения не являются небольшими, маловероятно, что они смогут преобразовать их вручную в любой короткий промежуток времени (или даже самостоятельно, поскольку, как представляется, ОП подразумевает «я намерен»).

Gartner Group проанализировала ручные миграции и предлагает, если все "похоже", фактический коэффициент конверсии составляет ~ ~ 150 строк / день, что возможно, потому что вы переводите более или менее непосредственно из рабочего отлаженного приложения.,(Насколько велико приложение в SLOC?) Итак, если у вас 75 000 строк кода, вы смотрите на минимум 500 человеко-дней.Вы могли бы доказать, что Delphi как языки программирования и C # похожи.Вы не можете обоснованно обосновать это для пользовательского интерфейса Delphi и Silverlight, поэтому эта оценка является нижней границей.

Есть такие, которые говорят: «просто выбросьте и перекодируйте его с нуля».Если ваша производительность не превышает 150 отлаженных строк кода в день [классические тексты по разработке программного обеспечения скажут вам, что он намного меньше этого], это займет у вас еще больше времени.Обычно это дает сбой, потому что вы в конечном итоге забываете о том, какие функции существуют в текущей программе, и заново обнаруживаете их на поздних стадиях разработки или, что еще хуже, после попытки повторного внедрения.Обычно происходит то, что старое приложение продолжает развиваться, пока строится новое (помните, что вы находитесь на расстоянии 500 человеко-дней от нового минимума!), И новое должно сыграть в догонялки с этими изменениями.Если приложение имеет какой-либо серьезный масштаб (например, миллион строк), это часто предотвращает возможность обслуживания нового приложения.Еще один способ думать об этом: «сколько времени потребовалось для создания исходного приложения?» И «почему создание замены должно быть намного проще?».YMMV, если вы можете творить чудеса.

Мое очень предвзятое мнение (я создаю инструменты перевода на язык), что один из наиболее практичных способов сделать это - автоматический перевод.Это тоже имеет свои издержки;они не являются готовыми предметами, независимо от того, что кто-то говорит вам.Вы настроили переводчик, и это также отнимает много энергии, но эта энергия пропорциональна размеру используемых библиотек language и (UI) , а неразмер приложения, поэтому он становится намного более эффективным, поскольку программа становится большой.Это все еще порядка сотен человеко-дней, чтобы кодировать и тестировать только для части перевода языка.Разница в том, что после настройки вы можете применить его к существующему приложению любого размера, в каком бы состоянии оно ни находилось. Есть больше сложностей, чем это, но этот подход преодолевает проблему «не догнать» ручных преобразований.и "не хватает кодировщиков для его ручного перевода".

Подробнее см. в моем ответе о том, как переводить между языками .

Если вашПриложение относительно небольшое, ИМХО нет хороших ответов.Ручной перевод или перекодировка, вероятно, ваш единственный (безобразный) выбор.

1 голос
/ 14 апреля 2011

Мое предложение будет заключаться в создании дополнений и обновлений «добавленной стоимости» для вашего приложения с использованием Silverlight по мере того, как возникает необходимость в дополнительных функциях, пока у вас не появится нечто похожее на полный продукт.

МнеРазработка Silverlight, кажется, занимает очень много времени, и UX для бизнес-приложений не сильно улучшен, скажем, в ASP.NET Ajax (если Ajax сделан правильно).Я полагаю, если бы вы сели сегодня и полностью переписали приложение достойного размера в Silverlight, то Silverlight был бы концом жизни до того, как ваша разработка будет завершена (если, конечно, вы не бросили в нее огромную команду)

...