Порт Delphi 7 Доступ к данным на C #

Question

У нас есть клиент-серверное приложение, написанное на Delphi 7 с внутренней базой данных Firebird. Код изначально начинался со слоя доступа к данным, но быстро распадался на доступ к данным в формах и различных единицах, разбросанных по проекту.

Мы хотели бы перейти на .NET в какой-то момент в ближайшем будущем, и, по моему мнению, лучше всего начать с того, чтобы сначала переместить DAL в .NET и реализовать его в текущем приложении Delphi. Затем мы можем еще больше портировать бизнес-уровень и, наконец, пользовательский интерфейс.

Итак, я ищу идеи от других разработчиков в отношении некоторых технологий / сред для изучения возможности переноса DAL в .NET. Моей первой мыслью было бы создать несколько веб-сервисов. Идея состоит в том, чтобы переместить текущее клиент-серверное приложение в .NET. Мы можем бороться с многоуровневым дизайном, веб-приложениями позже. Может быть, правильный ответ - начать с нуля?

Любые мысли или идеи будут с благодарностью.

Answer 1

Волшебного рецепта для этого нет. Я также разработчик Delphi, который сейчас работает в мире .NET.

Delphi - это крайности. Каждый язык может иметь хорошо написанное или плохо написанное программное обеспечение. Но в Delphi, когда приложение хорошо написано, это рай. Когда это не так, это ад. Если вы понимаете, о чем я. Delphi выводит RAD на совершенно новый уровень. Таким образом, вы можете писать программы очень быстро. Но он становится неорганизованным ... Вроде как WinForms, если вы напишите эту команду SQL Insert в событии Button:)

Вот мои мысли:

• Когда вы переходите на .NET, используйте C #, пожалуйста. И не оглядывайся назад.
• Вы должны окончательно начать со слоя данных.
• Если вы хотите сохранить свой Delphi UI и заставить его работать с вашим .NET DAL, вы можете даже удивиться, не желая переходить на WinForms. Некоторые люди могут расстраиваться из-за этого, но время покажет ...
• Возможно, вы захотите внедрить свой DAL в качестве веб-сервисов. На обеих сторонах вашего программного обеспечения есть много возможностей для обучения. И есть также возможность многократного использования!
• Начните свой DAL с нуля. Вы не пожалеете.
• Не запускать интерфейс с нуля. Попробуйте использовать существующий пользовательский интерфейс. Пользовательский интерфейс требует времени. Если вам нужно просмотреть все существующие экраны, вы избавитесь от плохих вещей, а затем подключитесь к новому .NET DAL. Но строить все с нуля - это ошеломительно, и это может привести к депрессии в долгосрочной перспективе.

Answer 2

Вы можете использовать Delphi Prism .
Это не Delphi, а Object Pascal для .NET.

Однако перенос из Delphi в Prism будет намного проще, потому что это и паскаль, и Embarcadero приложил усилия для облегчения перехода.

Поскольку он использует .NET, а не VCL, это , а не простая перекомпиляция, но вы можете использовать намного больше, чем в противном случае.

Answer 3

Я нахожусь в очень похожей позиции. См. Вопрос

Сначала я решил использовать WCF, но импортер Delphi WSDL просто не смог его взломать, сейчас я использую веб-сервисы ASP.net asmx, и совместимость значительно улучшилась.

Мы применяем поэтапную миграцию с толстого клиента с непоследовательным встроенным SQL, хранимыми процедурами и до 900 - 1200 строковых методов к многоуровневому решению. Как только функциональность на стороне сервера будет внедрена, мы переходим к реализации изменений в клиенте Delphi. Это позволяет существующему приложению продолжать работу, а тестирование и развертывание можно выполнять поэтапно.

Я начал с реализации DAL и использования платформы Entity, у нас есть все наши таблицы данных, представленные в виде объектов, и мы обмениваемся данными с клиентом, используя объекты передачи данных для каждого объекта.

Затем бизнес-логика будет перенесена из функциональной области в функциональную область, и, наконец, клиент просто сделает то, что должна сделать форма клиента, что позволит пользователю взаимодействовать с приложением.

Одной из основных причин, по которой мы пошли с EF, было разрешение Visual Studio автоматически генерировать классы delphi с отслеживанием изменений (все еще работающим над этим) и логикой сохранения данных путем настройки шаблонов t4.

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

Все это даст нам возможность быстрее выполнять индивидуальные запросы клиентов на сервере без ущерба для дизайна клиента.

Для тех, кто спрашивает, почему и настаивает на том, что это всегда плохая идея, имейте в виду, что в некоторых случаях (например, в моем) эти хорошо используемые приложения очень сложны, и не все разработчики Delphi до сих пор пытаются оправдать сомнительные дизайнерские и программные решения. В настоящее время добавление новых функциональных возможностей - всегда азартная игра, когда переменные имеют несколько значений, и для приложения такого размера среда разработки Delphi 2010 была неадекватной, создавая настоящую головную боль для обслуживания после выхода из Visual Studio. Не поймите меня неправильно, я научил Delphi взяться за эту разработку, но способ, которым этот исторический продукт был написан (в Delphi 5), совершенно неустойчив.

Вопрос не в том, почему, а во многих случаях: как долго вы можете позволить себе игнорировать проблему, прежде чем ее заставят выполнить основную переписку или отказаться от продукта?

Answer 4

Это похоже на то, где DataAbstract может быть полезным.Он предлагает поддержку .Net и Delphi (и более того, Java уже в разработке).

Это позволило бы создать сервер с использованием C # и подключить клиентов Delphi через промежуточное ПО DA.

В качестве первого шага ваше приложение может быть перемещено на сервер на основе Delphi иклиент , и когда логика связи C / S работает, вы можете создать эквивалентный сервер в C # и затем переключиться.

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

Answer 5

Хотя я думаю, что переписывание - это всегда ошибка, вы также можете начать с того, что начинаете с любого технологического испытания: создать прототип. Установите коннекторы firebird ADO.net и напишите свой DAL на C #.

Переписать существующее приложение - это всегда больше, чем просто исправить свое текущее приложение. Всегда. И, в конце концов, вы потеряете переносимость, а не приобретете ее.

Если бы я собирался переписать приложение Delphi во что-то другое, и это был даже не нативный код, это была бы Java, а не .net. Несмотря на это, я повторю свой первый пункт; Переписывание - это пустая трата времени и денег, и в любом реальном бизнесе, в котором я когда-либо видел их, они ВСЕГДА были ошибкой. И все же люди решают делать это снова и снова.