経験豊富な WPFers にとって、WPF、Silverlight、および Silverlight OOB アプリケーションとコンポーネントはどの程度再利用可能でしょうか? 重複はどのくらいありますか？
たとえば、アプリケーションを 1 つ作成し、前述の 3 つの方法で簡単にデプロイできるでしょうか?
理想的には、できるだけ少ないコードを記述し、さまざまなシナリオで展開できる柔軟性を持ち、展開に応じて特定の機能を有効にしたいと考えています。WPF ファミリのテクノロジは、何気ない観察者にとっては良い出発点のように思えますが、それは本当でしょうか?
答えの簡略版は次のとおりです
。 1. Silverlight は、おおよそ WPF のサブセットです。
2. ブラウザー アプリの Silverlight と Silverlight OOB アプリは、まったく同じフレームワークで実行されます。単なる展開の違いです。
3. 一部の OOB アプリは「信頼できる」アプリとしてインストールでき、ブラウザ アプリよりもセキュリティ制限が緩い。
WPF アプリは、Silverlight アプリで利用可能なフレームワークの小さなサブセットでは利用できない .net フレームワークの多くの機能を使用する可能性が高いため、WPF アプリを Silverlight に移植することは非常に困難になる可能性があります。これはおそらく避けたいことです。
Silverlight アプリの WPF への移植は、かなり簡単になる可能性があります。WPF にはない機能が Silverlight にあるため (ただし、逆ほど多くはありません)、これはまだ難しい課題です。機能の差分に加えて、Silverlight/WPF アプリを実行する実際のフレームワークが異なるため、移植中に 2 つのアプリの間にある程度の動作の違いが生じる可能性があります。
Silverlight と Silverlight OOB アプリは同じフレームワークで実行されています。両方の場所でまったく同じアプリ バイナリを実行することができます。ほとんどの場合、それらは同じように動作します。いくつかの違い: ブラウザー内アプリは、html dom へのアクセス、javascript の呼び出しなどのブラウザー機能に依存できます。OOB アプリはブラウザーで実行されないため、明らかにこれは当てはまりません。また、「信頼された」OOB アプリを扱っている場合、ブラウザーでセキュリティ上の理由で禁止されていることを行うことができます (例: COM 相互運用)。
3 つの場所すべてで実行されるアプリを作成する場合、私のアドバイスは、自己完結型のブラウザー内 Silverlight アプリとしてアプリの構築を開始することです。つまり、アプリをホストしている Web ページに依存せず、必要なすべてのリソースが xap パッケージ内に含まれています (Web サーバー上のパッケージの隣にあることに依存するのではなく)。このようなアプリを Silverlight OOB アプリに移植するのは簡単です。ほとんどの場合、Visual Studio でチェックボックスをオンにするだけで完了です。それを WPF に移植するのはかなりの作業量になりますが、他の方法で移植するよりははるかに優れています。