Web アプリを .NET 1.1 から .NET 3.5 にアップグレードする説得力のある理由は何ですか?
9 に答える
問題は「すべきかどうか」ではなく、機能と追加されたコンパイル時のチェックに関してです。1.1 フレームワークから抜け出し、2.0 フレームワークに移行することはほぼ当然のことです。問題は、どのくらいの速さで移植する必要があるかということです。何を変更する必要がありますか?
最初のステップは、アプリケーションを .NET 2.0 に移植することです。その理由は、.NET 2.0 には以前には存在しなかった多くの機能があり、以前の機能は非推奨になったためです。(ASP.NET では、2.0 で廃止された多数の機能がありました)。
.NET 2.0 では、より強力なタイプ セーフ、null 許容型、およびフレームワークの変更が可能です。2.0 は (私が考えるに) .NET プラットフォームの最初の「実際の」リリースを表しています。これは深刻な競争相手であり、1.1 で使用しているフレームワークの一部が 2.0 で変更されていることがわかります。
これは単純な「コードを移植して利益を得る」というシナリオではありません。利点が必要な場合は、一部のコードを書き直す必要があります (特に、ジェネリックに関するもの)。しかし、より大きな .NET フレームワークでさえ、「舞台裏の変更」が非常に多いため、段階的に移植する必要があります。1.1から 3.5 に直接ジャンプしないでください。
1.1 - 2.0
.NET 2.0 と .NET 3.0 の間には多くの変更点があります。全体のパラダイムシフトがありました。(確かにそれは自発的なシフトですが)。 ウィキペディアにはそれに関するセクション全体がありますが、ここで (いくつかの!) 変更を行います。
.NET フレームワークの変更
- Windows プレゼンテーション ファウンデーション (WPF)
- Windows コミュニケーション ファンデーション (WCF)
- Windows ワークフロー ファンデーション
- Windows カードスペース
C# の変更点:
明らかに、もっと来ます。1.1 から 2.0 へのジャンプだけでも、リリース サイクル全体の価値があります。
.net 1.1 は非推奨であり、それ以上開発されていません。セキュリティの問題についてはわかりません。しかし、一般的には放棄されており、2.0 の時点で、Microsoft は新しいバージョンでの下位互換性を保証していますが、これは 1.1 には当てはまりません。
移動する機会があれば、移動してください。新しい言語機能を手に入れ、フレームワークが絶えず構築されていきます。必要に応じてlinq、Silverlightのサポート、もちろんジェネリックなどを入手できます。
実際、私は最近、.NET 1.1 から .NET 2.0 へのコード ベース全体の変換を完了しました。.NET 3.5 は、実際には .NET 2.0 の単なる拡張セットであり、完全に新しいベースではないことを考慮してください。
違いは、多くの部分で非常に重要です。私にとって、.NET 1.1 はまったく「飼いならされた」ものではなく、膨大な量のコードが必要でした。さらに、VS 7 は .NET 1.1 に対して使用する必要があったため、古いツールが必要でした。
Web アプリの場合、別の Web 構成が必要でした。これは、.NET バージョンを公開するため、さらに複雑になります。「.NET 3.5 には新しい機能があるため、それに移行する必要があります」という動きには入らないでください。潜在的なツールの使用ではなく、要件に基づいて決定を下す必要があるためです。多くの著者が正しく指摘しているように、フレームワーク全体を構成する機能の半分を使用しない可能性は十分にあります。
一方、少なくとも .NET 1.1 から .NET 2.0 に移行することをお勧めします。
ジェネリック、ラムダ、LINQ、忘れていた他の多くのことは確かです。
.NET 3.5 へのアップグレードには、説得力のある理由がいくつかあります。しかし、他の人が指摘しているように、3.5 は大部分 (完全ではないにしても) 2.0 の拡張にすぎません。ただし、2.0 は、移行する価値のある多数の機能をテーブルにもたらします。そうは言っても、私の考えでは、移行する場合、3.5 に移行するだけでなく 2.0 に移行するのはばかげているように思えます。
拡張メソッドだけでも非常に便利です。私は自分が思っていたよりもはるかに頻繁にそれらを使用していることに気づきました。さらに、3.5 の新しい機能の多くはそれらに基づいています。ジェネリックは、開発の大部分を大幅に簡素化します。また、C# でコーディングしている場合は、自動セッターとゲッターが役立ちます。ラムダ式は私にとってまだ比較的新しいものなので、話すことはできませんが、他の人がラムダ式を特に便利だと思っていることは理解しています。
WPF はアプリケーションを作成するまったく新しい方法を提供し、私はそれを使用しました。それは大きな期待を示しています。残念ながら、私が (個人的に) 値すると思うほど広く採用されているようには見えません。うまくいけば、それは時間の経過とともに変わるでしょうが、それはマイクロソフト自身がより積極的にプッシュし始めるかどうかに依存します.
フレームワーク自体に関する限り、以前は 1.1 に欠けていた多くの機能が改善または提供されていることがわかりました。Framewok は成熟するにつれて、私たちがよく実行するタスク (ディレクトリ サービス、FTP アクセス、名前付きパイプなど) のコードを書く必要が少なくなる方向に向かっているようです。ざらざらしたエッジが滑らかになっています。
要するに、3.5 に移行するということは、新しいアプリケーションをより少ないコードで作成できることを意味し、既存のアプリケーションをリファクタリングして使用するコードを減らすことができるということです (その目的のためだけにそうすることをお勧めするわけではありません)。3.5 では、さまざまな生産性ツールを自由に使用できます。私の個人的な意見では、これらのツールだけでも飛躍する価値があると思います。
しかし、あらゆるビジネス上の決定と同様に、プロジェクトの状態と、コードベースを移植するときに発生する可能性のある潜在的な欠陥とを比較検討する必要があります。これまでの私の経験では、いくつかの障害に遭遇しましたが、操作全体を停止させるには十分ではありませんでした. それにもかかわらず、どのような移行でも、コードが壊れる可能性が常にあります。心に留めておく必要があります。
ASP.NET 2.0 以降で設定されたプロバイダー フレームワークが、本当にもっともな理由だと思います。ユーザーがログインしているかどうか、またはユーザーが持っているロールのリストを、それらをチェックするために使用される基本的なメカニズムを気にせずに取得できることは、大きな利点です。
最大の違いは、.NET 2.0 CLR に移行することです (これは、現在の .NET が実行されているのと同じ CLr です)。
これは、豊富なバグ修正と CLR レベルの Generics サポートがあることを意味します。残りの変更は、基本クラス ライブラリの変更と、コンパイラの新しい言語機能です。
編集して続行しますか?また、ジェネリックスとnull許容型により、作業が少し楽になります。
WCF、WF、WPF、CardSpace などを忘れないでください。