2009-02-28 1 views
2

大規模なvb6アプリケーションを.NETに移植する作業を進めています。現在のアプリケーションは、ローカルアクセスデータベースのセットと通信するデスクトップアプリケーションです。アプリケーションには約200のフォームがあり、約100のテーブルがあります。画面は大部分が複雑です。大部分は、マスターと詳細の関係、埋め込みスプレッドシートの行数、動的に生成される編集コントロールを表示します。大規模なvb6アプリをWebまたはwinformsに移動する。あなたが決める!

.NETに移植します。私は彼らがそれをWebベースかwinformsにしたいかどうか分からない。私にとっては、アプリケーションがwinformsに適しているようです。ありがたいことに、アクセスデータベースは選択にかかわらずSQL Serverに置き換えられます。リサイズのための

私の理由:

  • リッチなUI。
  • クライアントキャッシング
  • 高速開発。 Winformsは、ASP.NETが従来のASPよりも光年の生産性が高いにもかかわらず、私にとって生産的です。私はまだwinformsで動作します。
  • 状態を管理することにより、より多くのデータを表示し、時間を節約できます。

私は、ビジネス/データ層を別々のライブラリに分割する予定です。ライブラリ内のビジネスオブジェクトは、winformsまたはWebアプリケーションのいずれかで使用できます。

winformsに最初に移植し、UIとビジネスロジックを明確に分離すると、ビジネスロジックを後でWebバージョンで再利用できるようになると思います。ビジネス/データ層がUI依存関係のない別個のライブラリにあるとすると、

最終的には私の決定ではありませんが、大型のWindowsアプリケーションをasp.netに移行した経験をお聞きしたいと思います。

大きなデスクトップアプリケーションをasp.netに移行した経験は何ですか?このようなプロジェクトにどのようにアプローチしますか?あなたはむしろwinformsまたはasp.netにこのアプリを移植しますか?どうして?

ありがとうございます! スティーブ

答えて

1

移行を簡単にするために、ポートを段階的に行うことをお勧めします。第1段階は、VB6デスクトップから.NETデスクトップへの移植です(Winフォーム)。

次に、2番目の段階で、必要に応じて.NETデスクトップのすべてまたは一部をASP.NET GUIに移動します。

VB6から.NETへのステップは関係なく、GUIの選択の、それ自身で作るためにチームのために非常に大きいです。段階的アプローチにより、あなたのチームは現在のアプリに似たアプリケーションスタイルで.NETを把握することができます。

再利用可能なライブラリにビジネスロジックを分離するために、あなたの目標は、これが機能するためのアプローチを上演するためには重要です。この方法をとると、使用するGUIタイプ(またはタイプ)についてより柔軟に対応できます。たとえば、あなたは必要に応じて、ユーザーがダウンロードすることができ、より複雑な画面を含むauxillary WindowsFormsアプリで、ASP.NETのWebサイトで提供されるすべてのシンプルな画面を持つことができ

。重要なのは、これらの両方が同じビジネスロジックライブラリを使用することであり、ほとんど同じアプリケーションに対する異なるインタフェースです。

ASP.NET(または一般にウェブ開発)全く異なる開発者の考え方が必要となる状態を扱うとき、クロスブラウザ、HTML/CSSなど

私は最近、大規模なDelphiのデスクトップのポート/移行に取り組みましたアプリを.NETに追加します。目標はASP.NETに移行することでしたが、既存のチームではWeb開発の経験が限られていて、ASP.NETを使用してdektopアプリケーションを再実装しようとしたため、これは完全に終了しました。私は、これは、Windowsフォームでの再作成画面と比較して、少なくとも最終結果が使用可能とエンドユーザーにいくつかの値を提供しますはるかに大きなリスクであることを言うと思います。

AjaxとjQueryは、Web GUIの豊富さを大幅に改善しましたが、既存のアプリでは、デスクトップアプリケーションで効率的に実装する方が簡単なデータのスプレッドシートプレゼンテーションなどの領域があるようです。

要するに、「理想的」とは、ビジネスロジックとルールを.NETに移行し、後でユーザーインターフェイスを簡単に「プラグイン」できるようにすることです。これは完了したと言われる方がはるかに簡単かもしれませんが、それは私が通常目指す目標です。

+0

私は最初にwinformに移植してからウェブに移植することに同意しません。誰が予算を得ようとしているのですか、そしてあなたがターゲットとしていることがわかっているなら、ASP.NETです。 –

+0

ターゲットがASP.NETであるかどうかはわかりませんが、それは問題のポイントです!また、SteveBが提供した詳細に基づいて、勝利フォームアプリがより良い選択と思われます。 – Ash

+0

また、ビジネスルールをカプセル化すると、Winndows FormsからAPS.NETへの「ポート」ではありません。必要に応じて、ASP.NETなどの.NETインターフェイスで使用できる一連のビジネスロジックアセンブリがあります。 – Ash

3

新しいASP.Net Webアプリケーションに移植する大きな利点の1つは、それをクリーンアップする機会が増えることです。

winformsに移動すると、画面に画面を表示するという大きな誘惑とプレッシャーがあります。ウェブに行くと、より基本的なレベルでリファクタリングと改善を行う機会があります。

私の会社は現在、かなり大きなレガシーVB6/AccessアプリをASP.Netに移植しています.AJAX(そして今はSilverlight)では、ウェブ上のUIに非常に高いレベルのビジュアル品質と複雑さを得ることができます日々。ユーザーのアクセスと展開の観点からも明らかな利点があります。

私はプロジェクトにアプローチする方法として、アーキテクチャを証明するための薄いスライス(単一の機能の実装)を構築し、次に優先度と複雑さに基づいて機能を追加する反復的なアプローチを使用して成功しました。

+0

これはチームの経験と質によって異なります。 VB6デスクトップからWeb/Silverlightへの移行は大きな飛躍です。私はDelphiデスクトップアプリケーションから.NETへの移行に取り組んだときにこれを見ました。彼らは当初Webルートに行ったが、結果はひどく、WebにデスクトップGUIを適用しようとした。 – Ash

0

すべて私に言えることは、あなたがやり直すべきではないということです! StackOverflow Podcastの1つでは、新しい言語のメリットを得るためにアプリケーションを書き直すべきかどうかを教えてくれましたが、答えはノーです! Joel Spolskyが与えた例は、Borland C++ Builderでした。彼らは最初からやり直したので、Microsoft VC++に敗れました。その後、Jeff Atwoodは、WordPressがPHPで書かれていても(私の意見では良い言葉ではありませんが)全体的な考え方がうまくいったと言いました。

主なポイント:あなたは強固な基盤の上に構築することにより得たすべての経験を失うので
が終わっ起動しないでください。

0

最初にオフ、Winformsが死んでいますです。なぜWPFが2年近く外に出ていたとしても、誰もがWinFormsで新しいデスクトッププログラムを開始するのは私の限界です。なぜ非常に時代遅れである技術(VB6)から、あなたのクライアントをすぐに時代遅れになる別のものに移行させるのですか?この間違ったを取るが、あなたはXPは、私は2009年にWinFormsのプロジェクトを開始するために、実際に無責任だと思うことを、古いバージョンのWindowsをサポートする必要がない限り、ここでWPF対欠点ですしないでください。

  1. XAML、WPFは、 Silverlightが中心でありMicrosoftです。
  2. WPFはWinformsよりはるかに強力です(少なくとも非常に豊富なUIを開発するのは簡単です)。
  3. WPFでのデータバインディングは、Winformsよりも先の量子の飛躍です。それはあなたの時間を節約します。
  4. WPFは安定しており、最後のいくつかのSPおよびバージョンでは大幅なパフォーマンスの向上が見られました。
  5. 古いMS技術と同様に、Winformsもすぐに死ぬでしょう。明らかに今は古い技術です。

Now for ASP.Net。これは、変換しているものがかなり簡単で内部的なアプリだと思えます。 ASP.Netはちょうどそのようなことに適しています。 ASP.Net MVCはほぼベータ版ではありませんが、WPFがWinFormsに対して持っているASP.Netに対する議論はまだありません。私たちはASP.Net + jQueryを仕事に使っており、とてもうまく動作します。私たちはあなたが調べるかもしれないSilverlightもやっています。私は本当にそれで働いて楽しんでいます。これが内部アプリの場合は、おそらくすべてのブラウザにインストールされているSilverlightプラグインに数えられるでしょう。 ASP.Net対WPFに行くの一般的なプロのため今

:別のデスクトップ環境にVB6のデスクトップから

WPF

  1. 簡単コードの移行。 VB.NetまたはC#に変換する必要がありますが、多くのロジックを保存することができます。 1つのステートフルな環境から別のステートフルな環境に移行します。 ASP.Netではそうではありません。
  2. テストするのが簡単です(特に複数のブラウザをサポートする必要がある場合)。
  3. 開発が速くなる可能性があります(特に複数のブラウザをサポートする必要がある場合)。

ASP.Net

  1. そのデスクトップアプリ(あなたが行うすべてのWebサーバーを更新している)の更新プログラムを配布する方が簡単。
  2. 正しく作成されている場合は、さまざまなデスクトップやモバイルデバイスでも使用できます。
  3. デスクトップアプリケーションの動的な性質の多くを、余分な開発努力で提供できます。
  4. 公開されている可能性のある将来の製品に活用することができます。

あなたのプロジェクトに幸運を祈る!

+0

彼らは今でも使用中のモニターの95%でフォントを正しくレンダリングできません。 – leppie

+0

@leppie、中国ではお茶の値段にしなければならないことは何ですか?私はとにかくあなたのコメントを得ることがわかりません... –

+0

"あなたの顧客/ユーザー、将来の開発者あなたの上司、誰に" 2009年にWinFormsプロジェクトを開始する "無責任な?私に休憩を与える!あなたはあなたの顧客が本当に必要とするものを理解することを聞いたことがありますか?それは新しい技術の選択ではなく、他のすべてを推進します。顧客がWPFのみが提供できるGUIを必要とする場合は、それを使用する場合は必ず、それを使用してください。経験する技術を使用し、時間とコストの中で実現可能な製品を提供することができます。 "WinFormsは死んでいる"あなたの心だけで、私の友人。 – Ash

0

あなたが本当に夢中になりたい、最新の技術を気にしない場合は、ASP.NETとSilverlight 3をご覧ください。 Mix 09のビデオを見ると、これに対処するいくつかの素晴らしい例があります。

さらに、Silverlightアプリケーションはブラウザから実行できないため、デスクトップエクスペリエンスを提供することができますが、コードなどを更新するたびに更新されます。そして、私は個人的にWindowsタイプのアプリケーションSilverlightを含む)は、データ入力の目的ではより優れており、Webベースのアプリケーション(Ajaxを使用すると助けになります)

関連する問題