web-dev-qa-db-ja.com

Silverlight、Wpf Webアプリ（xbap）またはClick Once？長所と短所

新しいプロジェクトを開始しており、どのWpf風の開発/展開戦略を採用するかを決定しようとしています。私たちの場合、数百人（数千人ではない）が使用する非常に複雑なビジネスアプリを検討しているので、クリックワンスアプリに傾倒しています。上司は、Silverlightアプリのアイデアが気に入っています。これは、展開が簡単であることを意味します。では、どちらの方向にジャンプする必要がありますか？

もちろん、その答えは「状況次第」です。では、それぞれの長所と短所は何ですか？

ボールローリングを開始します（編集artur carvalho ）からのいくつかの回答に追加されました：

Silverlight

  • 長所

クロスブラウザ
完全なフレームワークは必要ありません。
ユーザーのより良い制御。ユーザーがログインする場合、アクティベーションキーなどを気にする必要はありません。
WindowsとMacで動作します。
すべてのユーザーのアプリを簡単に更新できます。

  • 短所

クライアントのファイルシステムなどと対話できません
完全なWpfと比較して機能が少ない（違いを文書化する優れたリソースを持っている人はいますか？）
単一ウィンドウ
シングルバージョン

Wpf Webアプリ（xbap）

  • 長所

完全なWpf。

  • 短所

単一のブラウザ
完全なフレームワークが必要
クライアントのファイルシステムなどと対話できません
単一ウィンドウ
シングルバージョン

Wpfクリック1回

  • 長所

完全なWpf
オフラインで作業できます
複数のウィンドウ
複数のバージョン（con？）
コンピューターの低レベル部分へのより良いアクセス
メンテナンスのためのダウンタイムなし

  • 短所

単一のブラウザ
完全なフレームワークが必要
少し（？）インストールが難しい。

c#.netwpfsilverlight
37
Mark

まず、Webクライアント（理想的にはMVC + jQuery）がその仕事をできないかどうかを評価します...

完全なクライアントが保証されていると仮定します。

クライアントを必要とするビジネスアプリの場合、私は完全なフレームワークとClickOnceを使用する傾向があります。ここでの主な違い（再展開）は、クライアントにフレームワークをインストールする必要があることです。ただし、それを過ぎると、ClickOnceの展開は非常に簡単です。実際、ClickOnceマニフェストの作成は、Silverlightなどよりもはるかに簡単です。これは、IDEあなた;あなたはどこかでファイルをホストする必要があります（ウェブURLかもしれません;ネットワークUNCかもしれません）。

これにより、はるかにクライアントでより多くの制御（および電力）が得られるだけでなく、使用する既存のリソースの範囲がはるかに広くなります（たとえば、必要に応じて、WPFサーフェスでいくつかのレガシーwinformコードを使用できます）。 「完全なフレームワークが必要」も最大のメリットの1つです。「完全なフレームワークを持っている」ということです。

3.5「クライアントプロファイル」の設定も検討する必要があります。これが実際にどれほど普及しているかはわかりませんが、知っておく価値はあります。

7
Marc Gravell

これが会社のみのアプリケーションなのか、一般向けのアプリケーションなのかはわかりませんでした。それだけであなたのためにそれを決定します。

会社だけの場合は、WPFのフルクリックを1回実行します。これはあなたにすべてを与えるでしょう。完全なフレームワークは問題ではありません。これはバックグラウンドで実行される1回限りのインストールであるため、決定に依存する必要はありません。短所：Windowsでのみ実行されますが、会社がWindowsのみである場合、これは問題にはなりません。

ただし、WPFアプリはリソースを大量に消費する可能性があるため、すべてのクライアントマシンがWPFアプリをスムーズに実行できるかどうかを知る必要があります。

インターネットアプリの場合は、Silverlightを選択してください。さまざまなオペレーティングシステムで実行されます。

3
Abdu

長所

  1. Silverlightプラグインは、開発者が、異なるバージョンの複数のブラウザーの複雑さに対処するのではなく、ブラウザーベースのアプリケーションに対して単一の一貫したランタイムをターゲットにできることを意味します。アドビシステムズ社のFlashにも同じ利点がありますが、純粋なHTMLやJavaScriptでは困難または不可能なビデオやマルチメディア効果も得られます。
  2. .NETランタイムをデプロイせずに.NETコードを実行します。 Silverlightプラグインにはカットダウンされた.NETランタイムが含まれていますが、大規模なダウンロードとWindowsインストーラーの複雑さを処理する代わりに、ユーザーは約4MBの小さなダウンロードをすべてブラウザー内で処理します。これまでの私の経験では、インストールはスムーズで簡単です。
  3. パフォーマンスは有望です。 Silverlightは、グラフィックスのレンダリングではあまり比較できないかもしれませんが、ネイティブコードへのJITコンパイルのおかげで、この素数計算機でうまく機能します。
  4. Moonlightのサポートは、Silverlightの公式のオープンソース実装があり、独自の側面を軽減することを意味します。
  5. SilverlightはXAMLを直接解釈しますが、AdobeのXML GUI言語であるMXMLは、コンパイル時にSWFに変換されます。実際、XAMLページは、Silverlightアプリケーションの展開に使用されるコンパイル済みの.XAPバイナリにリソースとして含まれています。 .XAPファイルは、拡張子が異なる単なるZipです。これは、検索エンジンがFlashの場合と同様に、Silverlightアプリケーション内のテキストにインデックスを付ける可能性があることも意味します。
  6. サードパーティのコンポーネントベンダーは、Silverlightアドオンをすでに使用しています。たとえば、Infragistics、ComponentOne、DevExpressなどです。
  7. .NETコードをクロスプラットフォームにします。 Macがどこにでも出現する中、Visual BasicまたはC＃コードをクロスプラットフォームのブラウザーベースのSilverlightクライアントに移行する機能はますます便利になります。明らかに、これは既存の.NET開発者にのみ当てはまります。これがSilverlightの主な市場だと思いますが、大きな市場です。同じことが次のポイントにも当てはまります。
  8. VisualStudioを使用します。 MicrosoftのIDEは、成熟した人気のある開発環境であり、ASP.NETのツールでもあるため、サーバー側のコードやSilverlightクライアントに使用できます。 Visual Studioに慣れていない人のために、SilverlightSDKはコマンドラインのコンパイルもサポートしています。
  9. 言語を選んでください。複数の言語のサポートは当初から.NETの一部であり、Silverlight 2.0で.NETランタイムを使用すると、クライアント側のロジックをC＃、Visual Basic、または動的言語ランタイム（DLR）のおかげでコーディングできます。Iron= RubyまたはIronPython。
  10. 分離されたストレージは、Silverlightアプリケーションにローカルファイルアクセスを提供しますが、アプリケーションに固有の保護された場所でのみ、この利点を得る比較的安全な方法を提供します。

短所

  1. AppleがiPhoneでFlashを許可しない場合、Silverlightにはどのような可能性がありますか？
  2. Silverlightはゲームに遅れています。 Flashは成熟しており、信頼性が高く、どこにでもあります。 Silverlight 2は、秋にのみベータ版がリリースされます（願っています）。これは私たちが関心を持っているバージョンであり、.NETランタイムが含まれているバージョンであり、Windows Mobileを含め、モバイルデバイスでのサポートはまだありませんが、これは後日不特定の約束があります。
  3. デザインツールはExpressionBlendとExpressionDesignですが、誰がそれらを使用しますか？デザインの世界ではAdobePhotoShopを使用しています。
  4. ExpressionBlendとVisualStudioの間にソリューションの互換性があることは良いことのように聞こえますが、特に現在のベータ版のように、わずかな非互換性がある場合は、実際には2つの別々のツールを使用する必要があります。
  5. 人気のあるH.264ビデオコーデックはサポートされていません。代わりに、Silverlightの高解像度ビデオはVC-1である必要がありますが、これはあまり一般的ではありません。
  6. オープンスタンダードではなく、独自のテクノロジーを促進するためのもう1つの取り組みです。
  7. はいLinuxはMoonlight経由でサポートされますが、いつですか？ Linuxの実装は常にWindowsとMacのリリースより遅れているようです。
  8. SilverlightはSOAP Webサービス、またはRESTただし、PUTまたはDELETEを使用しないが、AdobeのActionScriptメッセージ形式のような最適化されたバイナリプロトコルがない場合）をサポートします（AMF）。これは、一部のシナリオでパフォーマンスが低下することを意味する可能性があります。
  9. Silverlightはブラウザーのみのソリューションですが、FlashはAdobe Integrated Runtime（AIR）を使用してデスクトップに展開できます。そうは言っても、はい、私はこれを見ました。
  10. Windowsで開発する必要があります。設計者はMacの数が不釣り合いに多いため、これはExpression設計ツールにとって特に問題です。
1
Deven

1。SilverlightはホスティングページからDOMにアクセスできますおよび
2。ホスティングページはSilverlightパーツにアクセスできます。
これはSilverlightにとって大きな+です

しかし、他のすべての制限はWPF/Windows-Forms Clickonceを使用
ファイルアクセス、マウスの右クリック、データベースアクセスの容易さ

1
Peter Gfader

PROとASP.NET Webフォーム

  1. ViewStateまたは「サプライズクラップ」はありませんoこれはSilverlightにも当てはまります。 Silverlightは、「デスクトップ」エクスペリエンスをエンドユーザーに提供し、Silverlightで使用されるViewStateはありません。
  2. サーバー側とクライアント側の高速化oSilverlightは、見方によってはクライアント/サーバー側で高速です。 Silverlightは、Silverlightの.NETサブシステムでコンパイルされます。マルチスレッド、LINQ、複雑なデータ構造などにアクセスできます。ASP.NETまたはAJAX/JavaScriptアプリケーションと比較して、クライアントの実行とサーバーBLLで通常処理されるいくつかの項目により、パフォーマンスが大幅に向上します。クライアントにダウンさせることができます
  3. 複数の関連ビューの簡略化されたモデルoSilverlightは、データとUIの完全な分離をサポートします。たとえば、Silverlightの別のコンシューマーが非常に強力であるために、個別のビューを作成するだけでこれをさらに進めることができます。 Silverlight内で同じMVC/MVPパターンを適用して、このレベルの抽象化を実現できます。 Jasonは、iPhone用に個別のビューを作成でき、Viewコンポーネントのみを変更する必要がある例について言及しています。これは、Silverlightにもさまざまなことに当てはまります。たとえば、SharePointに移植したい大きなサイズのSilverlightアプリがあります。 SharePointの「小さいビュー」を作成して、UIにうまく収まるようにすることができます。さらに、SilverlightMobileは現在プライベートテスト中です。同じ非常に強力なレベルの抽象化が、Silverlightアプリケーションの「モバイルビュー」の作成にも適用されると思います。
  4. ユニットテスト可能oSilverlightには、ユニットテストフレームワークも含まれています。ここからダウンロードできます： http://code.msdn.Microsoft.com/silverlightut/
  5. 実行していない場合の課題IIS 7 o Silverlightは、IIS 6またはIIS 7またはApache。これは、SilverlightがASP.NETMVCよりも優れている機能の1つです。
  6. クライアントのキャッシュoASP.NET WebフォームまたはMVCでは、サーバーでキャッシュしています。 Silverlightを使用すると、分離ストレージを介してクライアントにキャッシュできます（必要に応じて数百メガバイトまで増やすことができます）。これにより、アプリケーションはホスティングサーバーを停止させることなく超高速で実行できます。

CONとASP.NET Webフォーム

  1. 既存のコードを変換するのが難しいoSilverlightは、ASP.NETWebFormsまたはMVCとはまったく異なるプログラミングプラットフォームです。多くのコードが変換されないだけでなく、クライアントレイヤーについても考慮する必要があります。既存のASP.NETサイト内の大きなモジュールを置き換える場合は、ほとんどの場合、完全な再アーキテクチャが必要です。
  2. 箱から出してすぐに使える最高のSEOではないoGoogleは数か月前にSWFファイルのスパイダーを作成して検索エンジンに追加し始めました。 Silverlightはおそらくまだここから離れていると思います。 Silverlight SEOでできることは、プラグインの周囲でメタデータタグを非常にうまく説明するための基本的なトリックです。
  3. データアクセスoSilverlightでのデータアクセスは、Webサービス/ WCF /ADO.NETデータサービスに制限されています。 ADO.NETまたはストアドプロシージャを介してデータベースを直接呼び出すことはできません。
  4. セキュリティoSilverlightはクライアントで実行されます。その後、あなたのビットの多くがインターネット上で野生で歩き回っています。さらに、一部のデータアクセス技術は完全なWS *標準セキュリティをサポートしていません。したがって、証明書ベースのトランスポートセキュリティを超えて、独自の配管コードを多数作成するか、次の改訂を待っています。 XAMLコードはかなり安全ではありません。 UIに知的財産を持っているアプリケーションは多くありません。 Silverlightでは、たとえばSilverlightSpyを使用して非常に簡単にリバースエンジニアリングできます。 Silverlightは、本質的に、ASP.NETMVCアプリケーションよりも少し安全性が低くなります。明らかに、Silverlightアセンブリを実際に使用する前に、暗号化/難読化することをお勧めします。
1
Deven

マーク、XBAPの「単一ブラウザー」とはどういう意味ですか？たとえば、XBAPはFirefoxで動作します。確かに.NETFrameworkが必要であり、MonoでWPFがすぐに（もしあれば）どこかにある可能性は低いので、Windowsで立ち往生しているのはその通りです。

0
IgorK

同期フレームワークをサポートするWPFClickOnceを検討します（ www.msdn.com/sync ）。これにより、ユーザーが企業ネットワークに接続していない場合に制限された機能をサポートできるようになります（これにより、SilverlightやXBAPなどのブラウザーベースの展開シナリオが排除されます）。

0
Philipp Schmid

あなたはオンライン対オフラインの議論の通常のものの賛否両論に追加することができます。いくつかのアイテム：

長所

wpf（オフライン）：

  • コンピュータの低レベルの部分へのより良いアクセス。
  • cPU使用率はローカルであるため、CPU負荷の問題が発生することはめったにありません。
  • ネットに依存しません。
  • メンテナンスのためのダウンタイムはありません。

silverlight（オンライン）：

  • ユーザーのより良い制御。ユーザーがログインする場合、アクティベーションキーなどを気にする必要はありません。
  • WindowsとMacで動作します。
  • すべてのユーザーのアプリを簡単に更新できます。

少し簡略化したところ、リストに灰色の領域があります。私はXBAPをいじくり回しただけなので、1つは省略します。短所は、長所を見た後で理解するのは難しいことではありません。

HTH

0
Artur Carvalho

このアドオンを介して、最近Firefoxで一度クリックすることはできません： https://addons.mozilla.org/en-US/firefox/addon/1608

0
John Rusk

すべてのWPFが必要ない場合は、最初にSilvelightで実行してみます。その後、後で必要になった場合に、より簡単にWPFに切り替えることができます。

ここでは、「少ないほど多い」という原則が適用されていると思います。WPFを使用すると、はるかに多くのオプションがあり、ユーザーのコンピューターにアクセスできることは事実ですが、時間の経過とともに、最終的にはヘルプよりも問題になる可能性があります。たとえば、多くの「ユーザーコンピュータ」リソースを使用するアプリケーションで、Windows XPからVistaに変更する必要がある変更の数を考えてみてください！

0
DaniCE