PowerBuilder 10 ビジネス アプリケーションを .NET に移行するためのアドバイスはありますか?
私の会社では、従来の PB アプリケーションを .NET (C#) に移行することを検討しています。良い経験でも悪い経験でも、共有したい人がいるかどうか疑問に思っています。
このアプリケーションは、10 個の PBL ライブラリ、いくつかの PFC、およびカスタム フレームワークを備えたかなり大規模なものです。多数の DLL 呼び出しも行われています。最後に、Microsoft SQL Server データベースを使用します。
「コア」アプリケーション コードを .NET に移植し、必要に応じてより高度な機能を移植することについて説明しました。
タイトルを見たとき、有名な PB ビゴットである私は潜伏するつもりでした。しかたがない。信任投票をありがとう、バーナード。
私の最初の提案は、自己欺瞞の言葉を捨てることです。「軽い」チーズケーキの半分を食べても、まだベルトを見失います. 移行には 10 分ほどかかる場合があります。あなたがすることは、書き換えです。時間は書き換えとして測定する必要があります。リスクは、書き換えとして測定する必要があります。また、設計作業は書き直しとして測定する必要があります。
はい、私は設計努力を言いました。"Migrate" は、ブラック ボックスからコードをポンピングし、元のコードを反映した翻訳が反対側から出てくるイメージを思い起こさせます。1994 年に何年も一緒に過ごしてきた同じ設計ミスを再現したいですか? 優れた品質のコードがあったとしても、PowerBuilder での優れた設計選択は、C# でのひどい設計選択である可能性があると思います。単純なコンバージョンは、プラットフォームのパワーと強みを無視していませんか? 今後 15 年間、優れた C# 設計を無視した結果を受け入れるつもりですか?
それはさておき、「.NET に」移行する動機について言及していないため、書き換えのリスクを軽減するために必要なオプションを提案するのは困難です。あなたの経営陣が、PowerBuilder の開発者は悪臭を放ち、オフィスから抹消する必要があると単純に判断した場合は、書き直しを頑張ってください。
単純に Windows フォーム、Web フォーム、アセンブリ、または .NET Web サービスを展開したい場合、または .NET ライブラリを活用したい場合は、Paul が述べたように、11.0 または 11.5 に移行することで、移行に近づく努力が必要になります。(特に Web フォームを使用して、新しいプラットフォームに適した設計が得られていることを再度確認して確認することをお勧めしますが、その労力は書き直しよりも大幅に少なくなるはずです。) WPF アプリケーションをデプロイする場合は、 1 年待つにはかなりの時間がかかりますが、PowerBuilder 12 を検討することは、努力する価値があるかもしれません。WPF の機能をうまく活用すれば、PowerBuilder は独自の強力な地位に立つことができます。
書き換えが将来確実に行われる場合 (シャワーのほうが安いようです)、変換を段階的に行うことをお勧めします。DataWindow.NET を使用すると、データウィンドウを持ち運ぶことができます。（今週のお気に入りの理論は、PowerBuilder 開発者は、組み込まれているすべての機能を再現しなければならないまで、データウィンドウを当然のことと考えているというものです）。リソースを消費し、印刷可能で、データにバインドされた動的 UI、組み込みの論理レコード ロックを使用した最小限の SQL の生成、およびイベントへのデータベース エラー変換を新しいアプリケーションに組み込むことは、大きな利点です。
また、PowerBuilder コードを .NET アプリケーションで使用できるものに変換することで、段階的に移行することもできます。前述のように、入手した PB 10 で COM オブジェクトを生成できますが、アセンブリを生成するには 11.0 または 11.5 に移行する必要があります。この値は、アプリケーションがどの程度適切に分割されているかによって異なります。ビジネス ロジックが非ビジュアル オブジェクト (カスタム クラス) に分割されるのではなく、GUI イベントと関数を介してスネークする場合、これの価値は疑問視される可能性があります。それでも、これはC# に完全に変換する前に修正する必要がある設計ミスです。これは、PowerBuilder アプリケーションを段階的および完全な変換への準備段階として維持しながら実行できることです。
間違いなく、PowerBuilder を使い続けていただきたいと思います。それができなければ、あなたが成功するのを見たいです。最初の一口を食べたら、最後まで食べなければならないことを忘れないでください。
そのベルトを見つける幸運、
テリー。
「コア コンポーネント」を .NET に移行して開始することについて言及されているようです。もうお察しのとおり、段階的なアプローチは賢明な決断だと思います。「コア」の定義については議論の余地があるかもしれませんが、逆の見方はどうでしょうか。思考の糧？(明らかに、これはダイエットを開始するのに間違った週でした。) PB が現在どこにあるかに基づいて、アプリケーションの機能 (たとえば、PB の売掛金、C# の買掛金) に沿ってアプリケーションを PB と C# に分割するのは難しいでしょう。機能する可能性のある分割は、GUI とビジネス ロジックです。前述のように、ビジネス ロジックを PB から C# が使用できる実行可能ファイルにポンピングすることは既に可能です。PB からコピーされたデータウィンドウと、COM オブジェクトまたはアセンブリとして送り出されたビジネス ロジックを使用して、C# で GUI を構築するのはどうでしょうか。逆に、PB で .NET アセンブリを使用するには、COM 呼び出し可能ラッパー。
または、PowerBuilder で C# 開発者をトレーニングするだけです。これは単なるうわさかもしれませんが、PowerBuilder の新しいマーケティング キャッチフレーズは「とてもシンプルで、C# 開発者でも使用できる」になると聞いています。;-)
上記で gbjbaanb さんが良い答えをくれたと思います。
考慮に値するその他の質問:
ソフトウェアが非常に貧弱で、会社のビジネスに悪影響を及ぼしている場合、私は書き直しに反対しているわけではありません。
また、Terry Voth が投稿するまでは、このスレッドを保釈しないでください。彼は StackOverflow に参加しており、トップ PB 担当者の 1 人です。
かなり大きい場合は、.net（またはWebベースのGUI）でフロントエンドを記述し、それを使用してPBコードと対話する方が、APIとして機能を公開できると仮定するとより良い結果が得られる可能性があります。
PB 9以降を使用している場合は、COMまたは.NET dllを生成して、C＃GUIで使用できます。新しい言語で書き直すよりも、これをお勧めします。
書き直しは決して特効薬ではないことを忘れないでください。最初に予想したよりも、常に時間がかかり、困難で、バグが多くなります。
大企業の PHB は、Powerbuilder はおもちゃの言語であり、C# のような新しい言語への移行は簡単で、低コストで実行できると考えています。実際、PB アプリケーションを他の言語に移行するには、少なくとも新しい言語でまったく新しいアプリケーションを開発するのと同じくらいの費用がかかります。結果として得られるアプリは、通常、元のアプリと比較して機能が失われ、ユーザーの不満につながります。私は多くの試みを見てきましたが、難しさとユーザーの問題のためにすべて失敗しました.
壊れていない場合は、修正しないでください。
いくつかの重要な .NET 統合を追加するPowerBuilder 11.5 (最近リリースされた)の調査に時間を費やすことをお勧めします。
新しい .NET コードを利用するために PowerBuilder 11.5 に移行することは、C# でアプリ全体を完全に書き直すよりもはるかに簡単です。
今週の私の持論は、PowerBuilder の開発者は、組み込まれているすべての機能を再現しなければならなくなるまで、データウィンドウを当然のことと考えているというものです。
私はその理論を支持します。私は数年前にあるプロジェクトで PB8 から Java への変換を試みましたが、最初の世代の HTML データウィンドウを使用したとしても、惨めに失敗しました。私の現在の雇用主は、現在の製品の DWO が 2,000 を超えているにもかかわらず、Datawindow.NET を使用せずに C# に移行することに必死です。実現が始まる日を楽しみにしていません.
OP - アプリケーションが異常によく構造化されていない限り (元は EA Server 用に作成されたものでしょうか?)、これはポートにはなりません。PB と .NET 環境では動作が異なりすぎて、プレーン ポートが十分に動作しません。これはいくら強調してもしすぎることはありません。実際に PB イベント モデルを使用している場合、「ポート」は失敗する可能性があります。
ロジック フロー (絡み合った UI とプロセス)、制御フロー (プロセスまたはデータの現在の所有者)、データ アクセス (UI、データ レイヤー、??)、および使用している DW イベント モデルの部分を確認する必要があります。コードから。ASP.NET について考えている場合 (私たちのように)、ユーザー インタラクション エクスペリエンス全体を変更する必要があり、それが他の考慮事項に反映されます。
コードとは直接関係ありませんが、ビルドの自動化は変更されます (一貫した PB ビルドのために PowerGen を使用します。MSBuild は非常に異なります)。インストールとセットアップも同様です。
大規模なアプリケーションでこれを検討している人は、DW への投資を無駄にしないように、DataWindow.NET の使用を真剣に検討しないのはかなり狂っていると思います。
良いかどうかわかりませんが、この（商用）製品を確認してください： PB.Net
