Delphi 7アプリケーションの.NETへの移行


Answers

それは私にとって本当に悪い考えのように聞こえる。

あなたの製品が.NETになるための技術的利点はありますか、それとも主にMicrosoftのショップになるという政治的決断ですか? クライアント/サーバーの場合、Delphiは非常に難しいです。 私はVS2005 / 8を使用しました。本当に本当に本当に誠実にDelphi for Win32の開発ほど良くはありません。 しかし、あなたがウェブに移行するなら、VSには明確な利点があります。

頑固なビジネス関係者が単にDelphiの使用を拒否すれば、KiwiBastardは正しい、IMOです。 最初にDelphi.NETに変換し、そこからVS2005に移行します。 それはより現実的なタイムラインであるため、または2010年

Question

Visual Studio 2005で既存のDelphi 7ビジネスアプリケーションを.NET 2.0に移行する方法に関するアドバイスはありますか?

Visual Studio 2005はすでに購入されており、同社はBorland / Codegearツールから離れたいと考えています。

このアプリケーションは、複数のサードパーティ製のUIコントロールとCrystalレポート10を利用して、単一のクライアントサーバーで実行可能です。

UIにはDelphiの種類に加えて、多くのSQL Server 2000ストアドプロシージャに広がる幅広いビジネスロジックがあります。 格納されたprocロジックの多くを.NETクラスに移行することも別の目標です。

顧客への影響を減らすために、可能であれば、完全な書き換え/変換ではなく、部分的にアプローチすることが望ましいでしょう。 前もって感謝します。

[更新]このタイプのシナリオでManaged VCLを使用している人は誰でも、良い、悪い、または醜い経験をしていますか?




短期間の変換とは、ネイティブのDelphiコードをCOMを使用するように変更し、.NET側がDelphiと共存できるようにすることです(または、おそらく他のいくつかの技術を使用して)

可能であれば、最初にDelphi.NETにアプリケーションを変換する方が簡単かもしれません。そして、少なくとも.NETのビットは少し簡単に通信できるようになります。

ちょっとした考え。




150万行のDelphiプロジェクトがC#に成功したことについての科学的報告がありました.Don RobertsらによるJohn Brantの報告があります。 彼は、AST上にDelphiパーサ、C#ジェネレータと多くの変換ルールを書いていました。 日々のビルド、ユニットテスト、難しいDelphi部品の書き換えなど、一連のルールを徐々に拡張することで、4人のチームができました。その中にはDelphiとC#の深い知識を持つ元の開発者がいます18ヶ月でソフトウェア。 John Brant&Don Robertsは、リファクタリングブラウザとSmaCCコンパイラ構築キットの最初の開発者であるため、そのように速く進むことはできません。

これは重要な投資でしたが、「元の開発と同じサイズ」ではありません。 作者は、Jeroenが指摘しているように、ツールや単発ツールを使用せずに直接書き直しを行うと、特に新しい要件が考慮されている場合は、その結果になる可能性が非常に高いと指摘しています。

作者は、異なるプロジェクトのために同じプラットフォームにとどまっている間、大規模なリファクタリングを行い、永続性インフラストラクチャを完全に置き換えました。 これは古い(BDE?)ベースのプロジェクトに関連する可能性があります。




RemObjectsからHydraを見ることをお勧めします。 これは基本的にあなたのためのcomのインターフェイスをラップし、あなたのDelphiと.Netアプリケーションの間のインターフェイスのためのオブザーバーのパターンを提供します。 .NetフォームをDelphiアプリケーション内のパネルに表示させることができます。 これは、機能を.Netに移行する際に、少しずつDelphiコードを置き換える素晴らしい移行パスを提供します。