タグ付けされた質問 「silverlight」

Model View View-Modelは、イベント駆動型プログラミング、特にXAMLおよび.NET言語を使用する.NETプラットフォーム上のWindows Presentation Foundation（WPF）およびSilverlightをサポートするUI開発プラットフォームをターゲットとしてMicrosoftによって開発されました。それ以来、Angular、Knockout、ExtJSなどの多くのJavascriptフレームワークがこのパターンを採用しています。 ほとんどのソフトウェアパターンと同様に、MVVMには適切な用途と悪用があります。MVVMの使用はどのような条件下で適切ですか？いつお勧めしませんか？

47 wpf  mvvm  silverlight  angularjs  xaml 

例＃1：MVVMアプリケーションにビューが表示され（ディスカッションの目的でSilverlightを使用しましょう）、新しいページに移動するボタンをクリックします。 例＃2：同じビューに別のボタンがあり、クリックすると、子ウィンドウ（ダイアログ）に詳細ビューが開きます。 ユーザーのクリックに応答するメソッドを持つボタンにバインドされたViewModelによって公開されるCommandオブジェクトがあることを知っています。しかし、それではどうでしょうか？どうすればアクションを完了できますか？いわゆるNavigationServiceを使用していても、何を伝えているのでしょうか？ 具体的には、従来のビュー優先モデル（WebやSL組み込みナビゲーションフレームワークなどのURLベースのナビゲーションスキームなど）では、Commandオブジェクトは次に表示するビューを知る必要があります。パターンによって促進される懸念の分離に関しては、これは境界線を越えるようです。 一方、ボタンがCommandオブジェクトに接続されておらず、ハイパーリンクのように動作する場合、ナビゲーションルールはマークアップで定義できます。しかし、ビューでアプリケーションのフローを制御し、ナビゲーションは単なる別のタイプのビジネスロジックではありませんか？（場合によってはyes、その他の場合はnoと言うことができます。） 私にとって、MVVMパターンのユートピア実装（および他の人がこれを公言していると聞いたことがあります）は、アプリケーションがヘッドレスで実行できるように（つまり、ビューなし）ViewModelを配線することです。これにより、コードベースのテストに最も広い領域が提供され、ビューがアプリケーションの真のスキンになります。そして、私のViewModelは、メインウィンドウ、フローティングパネル、または子ウィンドウに表示されるかどうかを気にするべきではありませんか？ このアプローチによると、各ViewModelに表示するビューを「バインド」するのは、実行時に他の何らかのメカニズムに依存します。しかし、ビューを複数のViewModelと共有したい場合、またはその逆の場合はどうでしょうか？ したがって、View-ViewModel関係を管理する必要があるため、子ウィンドウ/ダイアログの表示など、ビュー間をナビゲートする必要がある場合に何を表示するかを知るために、MVVMパターンでこれをどのように実現しますか？

33 design-patterns  silverlight  mvvm 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または詳細な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 6年前に閉鎖されました。 最近、WPFとSilverlightの開発と歴史に関する記事/ブログ/コメントをいくつか読みました。一部のフォーラムでは、多くの開発者とユーザーがWPFアプリケーション（Visual Studio 2010など）のパフォーマンスを批判しています。実際、Flashと比較したSilverlightの市場シェアはそれほど高くありません。PDC 2010では、Bob Muglia氏は「Silverlightの戦略と今後の焦点が変わった...」と言っており、Microsoftは将来HTML5をプッシュしたいと考えています。 さらに、Microsoftは、HTML8がWindows 8およびWindows Phone 8（「Mango」）プラットフォームのコア部分であることを発表しました。 最近、Silverlightの学習を開始しましたが、非常に優れた強力なテクノロジーを（私の意見では）学習するために時間を費やすべきかどうかを自問する必要があります！？彼らには未来がありますか？（Windows）デスクトップ（クライアント）アプリケーションには未来がありますか？いわゆる「リッチインターネットアプリケーション」には未来がありますか？または、HTML5はソフトウェア開発の「絶対的な真実」になりますか？ あなたの意見とあなたはどう思いますか？

24 programming-languages  .net  wpf  html5  silverlight 

MVCとMVVMの違いがはっきりとわかりません。ViewModelのCommandは、ControllerのActionメソッドに似ていると思います。また、コントローラーとViewModelの両方が、データバインディングを介してモデルの状態を変更した後、それ自体を更新するようにビューに通知します。2つのパターンの主な違いは何ですか？

21 asp.net  design-patterns  silverlight 

多数の値の変換を必要とするビューを持つWPFアプリケーションに取り組んでいます。当初、私の哲学（XAML Disciplesに関するこの活発な議論に一部影響を受けました）は、ビューのデータ要件のサポートについて厳密にビューモデルを作成することでした。つまり、データを可視性、ブラシ、サイズなどに変換するために必要な値の変換は、値コンバーターと多値コンバーターで処理されます。概念的には、これは非常にエレガントに見えました。ビューモデルとビューの両方に明確な目的があり、うまく分離されます。「データ」と「外観」の間に明確な線が引かれます。 まあ、この戦略を「古い大学の試み」にした後、私はこの方法で開発を続けたいかどうか疑問に思っています。私は実際に、値コンバーターをダンプし、（ほとんど）すべての値変換の責任をビューモデルの手に直接置くことを強く考えています。 値コンバータを使用する現実は、明確に分離された懸念の見かけの価値まで測定しているようには見えません。値コンバーターの最大の問題は、使用するのが面倒なことです。新しいクラスを作成し、実装するIValueConverterかIMultiValueConverter、値をobject適切な型にキャストし、DependencyProperty.Unset（少なくとも多値コンバーターの場合）テストし、変換ロジックを記述し、コンバーターをリソースディクショナリに登録する必要があります [下記の更新を参照]、最後に、かなり冗長なXAMLを使用してコンバーターを接続します（バインディングとコンバーターの名前の両方にマジックストリングを使用する必要があります）[以下の更新を参照]）。特にVisual Studioのデザインモード/ Expression Blendでは、エラーメッセージはしばしば不可解であるため、デバッグプロセスもピクニックではありません。 これは、すべての価値変換を担当するビューモデルを作成するという代替策が改善であると言っているわけではありません。これは、草が反対側でより緑であるという問題である可能性が非常に高い。関心事のエレガントな分離を失うことに加えて、派生プロパティの束を記述し、RaisePropertyChanged(() => DerivedProperty)ベースプロパティを設定する際に慎重に呼び出す必要があります。これは、不快なメンテナンスの問題であることがわかります。 以下は、ビューモデルに変換ロジックを処理させ、値コンバーターを廃止することの長所と短所をまとめた最初のリストです。 長所： マルチコンバーターが排除されるため、総バインディング数が少なくなります 少ないマジックストリング（バインディングパス+コンバーターリソース名） 各コンバータを登録する必要はありません（さらにこのリストを維持します） 各コンバーターを作成する作業が少なくなります（インターフェイスの実装やキャストは不要） 変換に役立つ依存関係を簡単に挿入できます（例：カラーテーブル） XAMLマークアップは冗長ではなく、読みやすい コンバーターの再利用は引き続き可能です（ただし、ある程度の計画が必要です） DependencyProperty.Unsetに不可解な問題はありません（複数値コンバーターで気づいた問題） *取り消し線は、マークアップ拡張機能を使用すると消える利点を示しています（以下の更新を参照） 短所： ビューモデルとビューの間のより強い結合（たとえば、プロパティは可視性やブラシなどの概念を処理する必要があります） ビュー内のすべてのバインディングの直接マッピングを可能にする、より多くのプロパティ RaisePropertyChanged派生プロパティごとに呼び出す必要があります（以下の更新2を参照） 変換がUI要素のプロパティに基づいている場合、コンバーターに依存する必要があります おそらくおわかりのように、この問題については胸焼けがあります。私は、リファクタリングの道を進むのを非常にためらっていますが、値変換を使用するか、ビューモデルで多数の値変換プロパティを公開するかどうかにかかわらず、コーディングプロセスが同じように非効率的で退屈です。 賛否両論ありませんか？価値変換の両方の手段を試した人にとって、あなたにとってどちらがより効果的であると思いましたか？他の選択肢はありますか？（弟子たちは、タイプ記述子プロバイダーについて何かを言及しましたが、彼らが話していることを理解できませんでした。これについての洞察はありがたいです。） 更新 本日、「マークアップ拡張機能」と呼ばれるものを使用して、値コンバーターを登録する必要をなくすことができることを発見しました。実際、これらを登録する必要がなくなるだけでなく、を入力しConverter=たときにコンバーターを選択するためのインテリセンスが実際に提供されます。：ここでは私が始まった記事ですhttp://www.wpftutorial.net/ValueConverters.htmlが。 マークアップ拡張機能を使用する機能により、上記の長所と短所のリストと議論のバランスが多少変わります（取り消し線を参照）。 この啓示の結果として、私はハイブリッド私がコンバータを使用するシステムで実験てるBoolToVisibilityと私は呼んでMatchToVisibility、他のすべての変換のためのビューモデル。MatchToVisibilityは基本的に、バインドされた値（通常は列挙型）がXAMLで指定された1つ以上の値と一致するかどうかを確認できるコンバーターです。 例： Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue=Visible, IfFalse=Hidden, Value1=Finished, Value2=Canceled}}" 基本的にこれは、ステータスが終了またはキャンセルのいずれかであるかを確認します。そうである場合、可視性は「可視」に設定されます。それ以外の場合、「非表示」に設定されます。これは非常に一般的なシナリオであることが判明し、このコンバーターを使用すると、ビューモデルの約15個のプロパティ（および関連するRaisePropertyChangedステートメント）が節約されました。を入力するとConverter={vc:、「MatchToVisibility」がインテリセンスメニューに表示されることに注意してください。これにより、エラーの可能性が著しく減少し、値コンバーターの使用が面倒になりにくくなります（必要な値コンバーターの名前を覚えたり検索したりする必要がなくなります）。 興味があれば、以下のコードを貼り付けます。この実装の一つの重要な特徴は、MatchToVisibilityそれがバインドされた値であるかどうかをチェックしていることでenum、それがあれば、それはチェックを確認するためにValue1、Value2なども同じ型の列挙型です。これにより、列挙値のいずれかが誤って入力されているかどうかの設計時および実行時チェックが提供されます。これをコンパイル時のチェックに改善するには、代わりに以下を使用できます（手で入力したので、間違えた場合はご容赦ください）： Visibility="{Binding Status, Converter={vc:MatchToVisibility IfTrue={x:Type {win:Visibility.Visible}}, IfFalse={x:Type {win:Visibility.Hidden}}, …

20 silverlight  wpf  mvvm  xaml 

多くのプロジェクトで.NetにさまざまなIoCコンテナー（Castle.Windsor、Autofac、MEFなど）を使用しました。彼らは頻繁に虐待される傾向があり、多くの悪い慣行を助長していることがわかりました。 特にプラットフォーム/フレームワークを提供する場合、IoCコンテナーの使用に関する確立されたプラクティスはありますか？フレームワークライターとしての私の目標は、コードをできるだけシンプルで使いやすいものにすることです。オブジェクトを作成するために、10行または2行だけでなく、1行のコードを作成したいです。 たとえば、私が気づいたいくつかのコードの匂いがして、良い提案がありません： コンストラクターの多数のパラメーター（> 5）。サービスの作成は複雑になる傾向があります。すべての依存関係はコンストラクタを介して注入されます-コンポーネントがオプションであるということはめったにありませんが（テスト中を除く）。 プライベートクラスと内部クラスの欠如。これは、C＃とSilverlightの使用に関する特定の制限かもしれませんが、どのように解決されるのか興味があります。すべてのクラスがパブリックである場合、フレームワークインターフェイスが何であるかを伝えるのは困難です。それは私がおそらく触れるべきではないプライベートな部分にアクセスできるようにします。 オブジェクトのライフサイクルをIoCコンテナーに結合します。多くの場合、オブジェクトの作成に必要な依存関係を手動で構築することは困難です。オブジェクトのライフサイクルは、IoCフレームワークによって頻繁に管理されます。ほとんどのクラスがシングルトンとして登録されているプロジェクトを見てきました。明示的な制御が得られず、内部の管理も強制されます（上記の点に関連し、すべてのクラスはパブリックであり、それらを注入する必要があります）。 たとえば、.Netフレームワークには多くの静的メソッドがあります。DateTime.UtcNowなど。多くの場合、これが構築パラメーターとしてラップおよびインジェクトされるのを見てきました。 具体的な実装によっては、コードのテストが難しくなります。依存関係を挿入すると、コードが使いにくくなります-特にクラスに多くのパラメーターがある場合。 テスト可能なインターフェイスと使いやすいインターフェイスの両方を提供するにはどうすればよいですか？ベストプラクティスは何ですか？

18 .net  silverlight  dependency-injection  ioc-containers  inversion-of-control 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、おそらく再開できると思われる場合は、ヘルプセンターをご覧ください。 8年前に閉鎖されました。 Microsoft は、開発者がHTML5とJavaScriptを使用できる新しいプラットフォームを含むWindows 8のデモを披露しました。 この新しいプラットフォームは、Windows 8向けの主な開発方法ですか？MicrosoftはHTML 5スタックを支持して.NETプラットフォームを段階的に廃止していますか？.NET開発者にとってWindows 8は何を意味しますか？

17 .net  html5  wpf  silverlight  windows-8 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 Silverlightが目を見張るような素晴らしいWebサイトを作成する可能性があることを認めると、それを使用して深刻なビジネス目的を持つ実用的なWebアプリケーションを作成する正当な理由はありますか？私が持っている新しい割り当てにそれを使用したい（それを学びたい）、それは私たちの組織で使用されているデータインターフェースを追跡するウェブベースのアプリケーションを構築することですが、それを正当化する方法がわかりません、自分自身にも。 これについて何か考えはありますか？正当化できない場合は、すでに100回使用した（と思われる）同じ古い疲れたまっすぐなASP.NETアプローチを使用してアプリを構築する必要があります。

14 asp.net  silverlight 

私は書き換えプロジェクトの最初の計画段階にあり、silverlight / silverlight oob / wpfを決定しています。最後にTL; DR。 これは、見込み客/顧客/予定カレンダーを処理するLOBアプリです。複雑すぎない。私は他の場所でこれらのオプションを独自に調査していますが、私は質問したいと思いました。大まかな初期要件/予測可能な問題は次のとおりです。 コマンドライン引数（SIP電話）を使用して、システム上のexeを呼び出せるようにする必要があります。 SLを問題にする ユーザーベースが分散されているため、ネットワークを通過するトラフィックをできるだけ制限し、厄介な同時実行の問題を回避したい WPFを使用してこれが問題であることがわかります ソフトウェアの導入/更新は非常にシンプルでなければなりません。一部のユーザーは非常に技術的ではありません（参照：70歳、初めてコンピューターを使用） これは、現在交換しているClickOnceアプリでは大きな問題ではなく、使用するマシンを制御できます。ただし、ユーザーがクリックして[インストール]ボタンをクリックする必要がない場合は、ユーザーにとってはより簡単です。これがSilverlight OOBでどのように処理されるのかわかりません。 同社はハードウェアの導入を迅速/簡単にする必要があるため、12か月でハード拡張を計画しています。新しい場所でインターネット接続を取得し、一部のコンピューターを接続して、専用のIT担当者やサーバーのセットアップを必要とせずに作業できるようにするという考えです。 SLを魅力的にする 他のサービス（金融ソフトウェア、asterixサーバー）との統合は当面の目標ではありませんが、システムの一部となることは最終的な目標です。単一のサービスがそれらのセカンダリサービスと統合するように設定されていて、そのすべてのデータをネットワーク経由で転送する必要がない場合、これははるかに単純/効率的になります SLを魅力的にする 複数の「バージョン」を作成することは不可能です。Silverlight + Silverlight Oobバージョンを維持するのがどのようなものかわからない（問題がある場合でも） WPFをより良いオプションにするかもしれません。 TL; DR：私の視点から見ると、Silverlightアプリは90％のユーザーに最適です。他の10％は、exeを実行する必要があるため、それを使用できません。Silverlight OOBは良い中間点かもしれませんが、現時点ではそれの実行モデルがどのようなものかわかりません（まだサーバー側コードの概念はありますか？そうであれば、それは理想的でしょう）と私はしません展開/更新がどのように機能するかを知っている。

10 wpf  silverlight 

WPFまたはSilverlightを使用する場合、コントロールの命名規則をどのように使用すればよいですか？XAMLマークアップでコントロールに名前を付けますか？"selectButton"や "btnSelect"などのコントロール名を持つcodeplexでのプロジェクトのサンプルを見てきました。あなたは何をお勧めします？

10 wpf  silverlight 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 Silverlight 5アプリケーションをしばらく使用しています。私はこのテクノロジーが好きで、Silverligtの開発で認定を受けるポイントに魅了されました。 しかし、Html5はこの時点で勢いを増し、新しいアプリケーションについての新しい波が押し寄せました。今、私はSlとhtml5のどちらで開発するかを考えています。私はこの件に関する何千もの投稿を読みましたが、アプリケーションをHTML5 SLに移行する方法があるかどうか、プロセスを助けるためのツールがあるかどうかわかりませんか？

9 html5  silverlight 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前休業。 .NET Frameworkには多くの「フレーバー」があります。 フル（「通常」） クライアントプロファイルサブセット WebブラウザーのSilverlight Windows Phoneの「Silverlight」 コンパクトなフレームワーク WinRT 新しいプラットフォームでC＃コードが必要な場合、MicrosotはBCL内の既存のアセンブリを使用するのではなく、完全なCLRを取得して小さなサブセットにストリップし、新しいアセンブリを作成して型を移動することを好むようです。 。たとえばSilverlightはList<T>、WPF と同じ実装を単に参照するのではなく、WPFに対して異なるクラス/メソッド（わずかに異なるシグネチャまたは非常に異なる実装を持ついくつかのメソッドにさえ）を持っています。 これは理想的なアーキテクチャですか、それともレガシーの兆候ですか？BCLをすべてのプラットフォームで実行し、それぞれに異なるプレゼンテーション/ IOライブラリを使用する必要はありませんか？または、BCLと他のライブラリが肥大化していて、それらを分割すると、多くの下位互換性の問題が発生し、受け入れられなくなりますか？ 空白のキャンバスから始めて、下位互換性について心配していなかったとしたら、現在の状況が実際に複数のプラットフォームを処理する最良の方法でしょうか？

9 .net  frameworks  silverlight 

私たちのチームは現在30を超えるモジュール（現在400人月と推定されています）で構成される次世代のHIS（病院情報システム）の構築に取り組んでおり、中央の場所でホストされ、地域を越えてアクセスされる可能性があります。したがって、主要なUI NFR（非機能要件）は次のようになります。 マルチブラウザ互換性 豊富なGUIを備えたページの高速読み込み 生体認証スキャナー、生体認証リーダーなどのハードウェアデバイスと統合する機能 開発の容易さ、メンテナンス（変更を組み込む）、開発サイクルの短縮 同じブラウザーウィンドウ内で複数のフォームを開く機能（追加のウィンドウを起動せずに） 長所： UIはブラウザに依存しないため、WebページがIE 7、8、9 ++、Chrome 8、9、18 ++、Mozilla Firefoxで動作することを心配する必要はありません（現在、多くの開発努力がこれに費やされています）互換性チェックと修正） モノリシックASP.Netアプリケーションとは異なり、アプリケーションをよりモジュール化できる可能性があります クライアントPCでの分離ストレージの使用 短所： Silverlightのメモリリークの問題。SLを使用して構築したいくつかのサンプルでそれらに直面し、レガシーXBAPアプリケーションで同じ問題を抱えています。次のリンクは、恐怖を 裏付けてい ますhttp://davybrion.com/blog/2010/08/silverlight-getting-worse-when-it-comes-to-memory-leaks/ /programming/5091636 / silverlight-4-memory-leaks マイクロソフトは、SLの将来について非常に大胆な態度をとっていません。彼らはHTML 5にもっと投資しているようです。SL5または6の将来のリリースも不確実です。 http://support.microsoft.com/gp/lifean45 http://www.zdnet.com/blog/microsoft/microsoft-our-strategy-with-silverlight-has-shifted/7834 http：//www.zdnet。 com / blog / microsoft / will-there-be-a-silverlight-6-and-does-it-matter / 11180 HISモジュールは、同じブラウザーウィンドウ内で複数のタブとして開きます（最大8つのタブを同時に開くことについて話しています）。そのブラウザインスタンスにどのくらいの負荷がかかり、メモリリークの問題にどのように影響しますか？ ASP.Net開発者向けの学習曲線 SLの別のスタックリンク /programming/251718/silverlight-wpf-web-app-xbap-or-click-once-pros-and-cons 中性 SEOの互換性は問題ではありません 私の質問は？ 上記（およびその他）の長所と短所を知って、SLを使用しますか MVVMパターンを使用して、SLをフロントエンドとして製品を構築する場合、明日UIを別のUI（ASP.Netまたはその他）に置き換えることができます。私の理解は、手直しはかなりのものになるだろうということです。コミュニティはどう思いますか？ 上記の分析（および概念実証の作成）にはかなりの時間を費やしてきました。私たちが見落としている重要な事実/決定的な要因はありますか？ この演習には多くの研究と努力が費やされているため、これを重複としてマークしないでください。 PS：過去6か月間、ASP.Net Webフォーム（MVPパターンを使用）を使用して製品を構築してきましたが、現在、上記の理由によるテクノロジーの変化を検討しています。

8 web-development  silverlight  web-design