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

私は、チームリーダーがSOLID開発原則の熱心な支持者であるチームに取り組んでいます。しかし、彼は複雑なソフトウェアをドアから取り出すのに多くの経験を欠いています。 すでに非常に複雑なコードベースであったものにSRPを適用した状況があり、現在では非常に断片化されており、理解とデバッグが困難になっています。 現在、コードの断片化だけでなく、プライベートまたは保護されている可能性のあるクラス内のメソッドが「変更の理由」を表すと判断され、パブリックまたは内部クラスおよびインターフェースに抽出されているため、カプセル化にも問題がありますアプリケーションのカプセル化の目標に沿っていない。 20を超えるインターフェイスパラメーターを受け取るクラスコンストラクターがいくつかあるため、IoCの登録と解決はそれ自体が怪物になりつつあります。 これらの問題のいくつかを修正するために使用できる「SRPからのリファクタリング」アプローチがあるかどうかを知りたいです。私は、いくつかの密接に関連するクラスを「ラップ」してそれらの機能の合計への単一のアクセスポイントを提供する多数の空の粗いクラスを作成する場合、SOLIDに違反しないことを読んだ過度にSRPされたクラスの実装）。 それとは別に、誰もが幸せなまま、開発努力を実践的に続けることを可能にする解決策は考えられません。 助言がありますか ？

57 c#  wpf  inversion-of-control  single-responsibility 

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 

私はWPFとWinFormsの主要なスレッドのほとんどを読みましたが、試行されたものと真の以前の技術（Winforms）と、その後継者（WPF）を決定するときに陥りがちな不幸なアンビバレンスに陥りました。 私は長年にわたりベテランのDelphiプログラマであり、ついにC＃へのジャンプを始めています。Delphiの仲間であるDelphiプログラマーは、Delphiで有名なAnders HejlsbergがC＃の設計者であることを知って興奮していることを理解します。DelphiのVCLカスタムコンポーネント、特にマルチコンポーネントウィザードや子コンポーネントのコンテナとして機能するコンポーネントの作成に関与するコンポーネントには強い依存症があります。 その背景から、DelphiからC＃に切り替えた皆さんが、私の最初のアプリケーションを作成するためのWinFormsとWPFの決定に役立つことを願っています。コーディングや、完全なオートコンプリートや適切なデバッガーサポートなどによってAPIの機能や呼び出しに関する情報がすぐに見つかるなど、バグの回避策を見つけることができるので、私は非常に焦ります。 。 2009年初頭のSOスレッドとコメントは、C＃UI開発コーディングを損なう可能性のあるフラストレーションの可能性に関して、WPFに大きな懸念を示しています。一方で、放棄されていなくてもすぐに交換される（WinForms）API技術を学ぶのに膨大な時間を費やすことは、同様に厄介であり、WPFの食欲をそそるGPUサポートを見つけます。 したがって、私のアンビバレンス。私はどちらの技術もまだ習得していないので、新たなスタートを切るまれな機会があり、大きな「未学習」曲線に直面する必要はありません。一方、WPFの使用がイライラしたり、私のような短気なRAD開発者に他の大きなマイナスの結果をもたらす場合は、WPFが同じレベルのサポートと使いやすさを達成するまでWinFormsを使い続けます。プログラマーとしての私の心理を具体的に示すために、私はVBを使用し、その後Delphiを使用して、初期のWindowsアプリの開発中に多くの開発者が苦労したWindows UIライブラリであるMFCによるコーディングの非常に大きな痛みを完全に回避しました。MFCを回避できたことを後悔したことはありません。 Anders HejlsbergがWPFおよび/またはWinFormsのアーキテクチャに手を携えているかどうか、そしてどちらかのコードベースで具体化された創造的なビジョンと使いやすさに不一致があるかどうかを知ることも安心です。最後に、Delphiプログラマーのために、WinFormsとは対照的にWPFを使用するとき、特にデバッガーのサポートに関して、「IDEショック」がどれだけ必要かを教えてください。2011年に更新された求人市場のコメントも歓迎します。

38 c#  wpf  winforms  delphi  microsoft 

私たちのチームはこれに分かれており、第三者の意見を聞きたかったのです。 アプリケーションを構築しているため、WCFサーバーで.Net WPFデスクトップアプリケーションを使用するか、jQueryを使用するASP.Net Webアプリを使用するかを決定できません。私はここでいくつかの仕様で質問をし、どちらの側を使用することの長所/短所が何であるかを見てみると思った。私には自分のお気に入りがあり、偏見を感じています。 理想的には、できるだけ早くソフトウェアの初期リリースをビルドし、その後スローダウンし、後で必要な追加の機能/コンポーネントをビルドするのに時間がかかります。何よりも、ソフトウェアが高速であることを望んでいます。ユーザーは1日中レコードを調べ、レコードの読み込みや画面の更新が遅れると生産性が低下します。 アプリケーションの詳細： 私は初期バージョンの約100の異なる画面を見積もっていますが、最初のリリース後に追加の多くの画面が追加される予定です。 リマインダーおよびイベントシステムに双方向通信を使用したいと考えています 現在、最大100人のユーザーをサポートする必要がありますが、最大500人のユーザーを増やすことができると言われています。 複数の場所があります 考慮事項（最初のケースではなく、将来のリリースの場合があります）： 初期リリース後に追加される追加コンポーネントのスペース（これらの多くは...おそらく最初のアプリケーションよりもここで動作します） キーボードナビゲーション パフォーマンスは必須です 初期バージョンへの生産速度 低いメンテナンスオーバーヘッド 今後のサポート ソフトフォン/スキャナーの統合 開発者： 過去数か月間WPFを学んでいたプログラマーが1人いて、これにWPFを使用することを提案したプログラマーがいました。 ASP.Netに精通しており、将来プロジェクトを支援する可能性のある2人目のプログラマがいますが、現在のソフトウェアのメンテナンスに時間を費やしているため、最初のリリースまでは作業していません。 両方で働いており、どちらかで快適な私がいます プロジェクト管理を行っている外部企業があり、ASP.Net企業です。 他に1-2人を採用する予定ですが、どの方向に進むのかを最初に知る必要があります 環境： 一般ユーザーは、ターミナルサービスを備えたWindows 2003サーバーを使用しています。RDP接続を介してWYSEシンクライアントを使用して接続します。管理スタッフは、XP以上のPCを所有しています。IEをWebブラウザとして使用することに制限されていますが、ユーザーは独自の解像度を指定できます。 その他の場所は、MPLS接続を介してネットワークに接続します それに基づいて、あなたは何を選択しますか、そしてなぜですか？

31 asp.net  wpf 

私はかつてMVVM / WPFプロジェクトを開始しました。このプロジェクトは最終的に構築および展開され、そのためにCaliburn.Micro MVVMフレームワークの多くを学びました。実際のところ、私はそのためにCaliburn.Microを使用せず、自分でMVVMの概念をいくつか実装しました（具体的には、ViewModelBaseとRoutedCommandクラスのみ）。 今、私は同じ行に沿ってやや大きなプロジェクトに割り当てられました：「シングルユーザーリッチクライアントオフラインデスクトップアプリケーション」、と言うことで、私はCaliburn.Microを使用することにしました。それが私の「問題」の始まりです。 私はこの有名なブログ記事で、タイトルに「MVVMを使用している場合、フレームワークが必要」と書かれています。 「フレームワークなしでMVVMのようなことをしようとすると、膨大な作業が必要になります。大量のコードを複製し、車輪を再発明し、考え方を変えるように人々を再訓練します。 少なくともフレームワークを使用すれば、コードの重複を避け、できれば車輪を再発明する必要がなく、人々の再訓練に集中できるようになります。通常、再トレーニングの部分は避けられませんが、フレームワークは配管コードと構造を提供し、プロセスを容易にします。」 最初に読むことに同意しますが、実際のアプリケーションでのCaliburn.Micro（CM）での実際の経験は、無知で見当識障害です。つまり、フレームワークはプロセスをまったく簡単にしませんでした。まったく逆です。むしろ、（あまりにも）非公式マニュアルにロブ・アイゼンバーグが提供する絶えず繰り返し実施例を読むこと、そして物事が動作するように設計されているように見える畳み込まれて、サンプル、およびその全く間接的なクラスとインタフェースの関係から、使用パターンを推測しようとしているベースの上を副作用は、あなたがベテランの天才でない限り、人間的には不可能だと思われます（暴言はごめんなさい。 任意の上記の些細なシナリオことは言うまでもありません私が働いたことがない何かである、IoCコンテナを伴うように思われ、どのように見える私も持っていないかもしれない問題を解決。私の問題やアプリケーションの領域について考えるのではなく、これらのことを学ぶためにプロジェクトにもっと時間を費やすつもりはありません。バナナが欲しかったのですが、CMはバナナのバスケットを持ったゴリラ（IoC）をくれました。 私が実際に実装したい少数のMVVM固有のクラスのみで構成される自作MVVMフレームワークに戻ることを検討しているので、ここで何かを失った場合に備えて、少なくともCMにチャンスを与えたいと思います。まったくの未経験と無知から「間違った方法で」物事を行うだけです。そして質問は次のとおりです。 「フレームワークは物事をより簡単に、より自然にする」というコンセンサスが広まっていますが、もし私がまったく逆になっているのであれば、フレームワークを使うべきではないということですか、それとも間違った方法で学習しようとしていますか？そもそもフレームワークを使用するべきではないという手がかりはありますか？または、単純なMVVM開発でCMを使用する方法を理解するための「正しい」方法はありますか

28 frameworks  wpf  mvvm 

私は長年Windows Forms開発者を経験していましたが、新しいWPFプロジェクトが間もなくやってくるので、WPFに移行する時が来ました。 Winformsの経験豊富な開発者にとって最善の方法は何ですか？ 短時間でWPFを学習するためのヒントや推奨事項を教えてください。 簡単なサンプルWPFソリューションと短い（ビデオ）チュートリアルはありますか？どの本をお勧めしますか？www.windowsclient.netは良い出発点ですか？公式のMicrosoftサイトに代わるものはありますか？

26 c#  .net  windows  wpf  winforms 

現在のところ、この質問は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 

私はウェブの世界でReduxとReactについて学び始めましたが、それについて学べば学ぶほど、WPFのMVVMスタイルのアーキテクチャ（特にビューをバインドするためにCaliburnを使用して） ViewModelsへ）。 Reduxには、状態の管理方法を指示するいくつかの簡単な原則があり、UIの更新、イベント処理、状態の変更をより予測可能にします。原則は次のとおりです。 単一の真実のソース（すべての可変状態は単一の共有オブジェクトに格納されます）。 状態は読み取り専用です。コード全体でコンポーネントによって変更することはできません。これは通常、WPFで発生することです。 状態は、純粋な関数によってのみ変更できます。 WPFのMVVMアーキテクチャを使用すると、インタラクティブビューを非常に迅速に構築できますが、さまざまなビューモデルやイベントがすべて状態を変更する場合のデバッグの問題は悪夢です。たとえば、ビューを変更してデフォルトのタブを設定しようとしたイベントが発生しましたが、Webサービスからのデータの非同期読み込みが完了していないため、タブはまだ存在しないため、何も起こりません 相互に更新する相互に関連するviewModelsコンポーネント間の複雑な相互作用を理解するために、私は何時間も図を描きました。 Reduxは、この状態の予測不可能性の一部を解決することを目指していることを理解しています。状態の管理を改善するために、WPFにうまく適合する類似の何か、またはアーキテクチャパターンがありますか？Reduxの原則が.NETでどの程度うまく機能するかは、まだ試していませんのでわかりません。おそらく誰かがいくつかのアドバイスを与えることができるいくつかの経験を持っていますか？

21 wpf  mvvm  state  redux 

多数の値の変換を必要とするビューを持つ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 

次のシナリオのビューモデルの作成にヘルプが必要です。 深い階層データ 同じデータセットの複数のビュー 各ビューは、アクティブな選択に基づいて、動的に変化する単一のビューです プロパティの値に応じて、タブコントロールにさまざまな種類のタブを表示する 私の質問： 各ビュー（VM1、VM2など）のビューモデル表現を作成する必要がありますか？ 1. Yes: a. Should I model the entire hierarchical relationship? (ie, SubVM1, HouseVM1, RoomVM1) b. How do I keep all hierarchies in sync? (e.g, adding/removing nodes) 2. No: a. Do I use a huge, single view model that caters for all views? これが単一のビューの例です …

18 wpf  mvvm 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 私は現在、WPF用のMVVMに頭を回そうとしています-私は頭を概念に回すつもりはありませんが、愚かなCRUDよりもbeatられたトラックから遠く離れていることの実際の要点についてです。 私が気づいたのは、多くのフレームワークであり、ほとんど/すべてのブログ投稿は「年齢」前のものです。 これは、古い帽子でブロガーが次のビッグシングに移行したからか、それとも言うべきことをすべて言ったからでしょうか。 言い換えれば、私はここに欠けているものがありますか？

18 wpf  mvvm 

私はデスクトップアプリケーションを開発しており、このアプリケーションを実行するにはいくつかの情報が必要ですが、この情報は変更されません（アプリの実行ごとにデータを読み込む必要がありますが、データは変更されません）。データは、アプリを実行しているコンピューターと同じコンピューターに保存する必要があります（クライアント側のストレージ？）。 また、ユーザーがこの情報を簡単に変更できない場合も優れています（ITの知識があまりないと仮定します）。 この種の情報はどのように保存すればよいですか？ローカルデータベース？アプリケーションと共に送信されるXML WPFを使用しています。

17 c#  design  data  wpf 

私は長い質問に謝罪します、それは少し暴言として読みますが、そうではないと約束します！私の質問を以下にまとめました MVCの世界では、物事は簡単です。モデルには状態があり、ビューにはモデルが表示され、コントローラーはモデルとのやり取り（基本的に）を行い、コントローラーには状態がありません。作業を行うために、コントローラーはWebサービス、リポジトリー、その他多くに依存しています。コントローラーをインスタンス化するとき、これらの依存関係を提供することに関心があります。アクション（コントローラーのメソッド）を実行するとき、これらの依存関係を使用してモデルを取得または更新するか、他のドメインサービスを呼び出します。一部のユーザーが特定のアイテムの詳細を表示する場合など、コンテキストがある場合、そのアイテムのIDをパラメーターとしてアクションに渡します。コントローラーのどこにも、状態への参照はありません。ここまでは順調ですね。 MVVMと入力します。WPFが大好きで、データバインディングが大好きです。ViewModelsへのデータバインディングをさらに簡単にするフレームワークが大好きです（Caliburn Micro atmを使用）。しかし、この世界では物事はそれほど簡単ではないと感じています。もう一度練習してみましょう。モデルには状態があり、ビューには ViewModel が表示され、ViewModelには（基本的に）モデルとのやり取りがあり、ViewModelには状態があります。するには、（1つ以上のモデルに、多分それ委譲し、すべてのプロパティを、それ手段は、それ自体の状態をあるモデルの1の方法または別の、への参照を持っている必要があります明確にするために）行いますViewModelには、Webサービス、リポジトリ、その他多くの依存関係があります。ViewModelをインスタンス化するとき、それらの依存関係だけでなく状態も指定する必要があります。そして、これは、紳士gentle女の皆さん、私をいらいらさせます。 あなたはインスタンス化する必要があるときProductDetailsViewModelからProductSearchViewModel（そこからあなたが呼び出されるProductSearchWebService順番に返されIEnumerable<ProductDTO>、あなたはこれらの事の1行うことができますか？私と一緒に、まだ、誰も）： call new ProductDetailsViewModel(productDTO, _shoppingCartWebService /* dependcy */);、これは悪いです、さらに3つの依存関係を想像してください。これは、ProductSearchViewModelそれらの依存関係も同様に引き受ける必要があることを意味します。また、コンストラクタを変更するのは苦痛です。 call _myInjectedProductDetailsViewModelFactory.Create().Initialize(productDTO);、ファクトリは単なるFuncであり、ほとんどのIoCフレームワークによって簡単に生成されます。Initメソッドは漏れやすい抽象化であるため、これは悪いと思います。また、Initメソッドで設定されているフィールドにreadonlyキーワードを使用することもできません。他にもいくつかの理由があると思います。 call _myInjectedProductDetailsViewModelAbstractFactory.Create(productDTO);So ...これは、このタイプの問題に通常推奨されるパターン（抽象ファクトリー）です。でも、実際に使い始めるまでは、静的型付けへの渇望を満たすため、天才でした。定型コードの量は多すぎると思います（私が使用するとんでもない変数名は別として）。ランタイムパラメーターを必要とする各ViewModelについて、2つの追加ファイル（ファクトリーインターフェースと実装）を取得し、4回の追加時間などの非ランタイム依存関係を入力する必要があります。また、依存関係が変更されるたびに、ファクトリーでも依存関係を変更できます。私はもうDIコンテナさえ使用していないように感じます。（Castle Windsorにはこれに対する何らかの解決策があると思います（それ自体の欠点があるため、間違っている場合は修正してください））。 匿名型または辞書で何かをする。私は静的型付けが好きです。 ええ このように状態と動作を混在させると、MVCにはまったく存在しない問題が発生します。そして、私は現在、この問題に対して本当に適切な解決策がないと感じています。今、私はいくつかのことを観察したいと思います： 人々は実際にMVVMを使用しています。したがって、彼らは上記のすべてを気にしないか、他の素晴らしい解決策を持っています。 WPFを使用したMVVMの詳細な例は見つかりませんでした。たとえば、NDDDサンプルプロジェクトは、DDDの概念を理解するのに非常に役立ちました。誰かがMVVM / WPFの似たような方向性を教えてくれたら、とても気に入っています。 MVVMをすべて間違っているのかもしれませんが、デザインを上下逆にする必要があります。たぶん、私はこの問題を全く抱えるべきではないでしょう。他の人が同じ質問をしているのは知っているので、私だけではないと思います。 要約する ViewModelが状態と動作の両方の統合ポイントであることは、MVVMパターン全体のいくつかの問題の原因であると結論付けるのは正しいですか？ 静的に型付けされた方法でViewModelをインスタンス化するための唯一/​​最良の方法は、抽象ファクトリパターンを使用していますか？ 詳細なリファレンス実装のようなものはありますか？ 状態/動作の両方を備えたViewModelがたくさんあるのは、デザインの匂いですか？

17 c#  design  wpf  mvvm 

私はVSでアプリケーションの構造を設定しようとしていますが、合理的なレベルに「試して」将来的に証明したいと思います。このアプリケーションは、慣例に従わなかった古いWinformアプリをWPFで書き直したものです。レイヤー、ティア、頭字語などはありません... これはかなり大規模なエンタープライズアプリケーションです。私のDBがそうであるように、Linq To SQLを使用する予定であり、ほとんどの場合、常にMS SQLになります。また、既存のスキルセットがあります。 できる限りMVVMとDDDをフォローしたいのですが、これらを組み合わせるとアプリケーションの構造が混乱します。いくつかの例を使って説明してみましょう。 MVVMに従うと、フォルダー構造は次のようになります。 Views Models ViewModels Helpers しかし、私のプロジェクト構造がこれに似ているかもしれない単純化されたDDD階層化アプローチにどのように適合しますか： MyApp.UI MyApp.Domain MyApp.Data Modelsドメインレイヤーに配置するのPersonですか、それともsayの3つのバージョンがありますか？これは、リポジトリとDBオブジェクトのドメインオブジェクトへのマッピングをどこに配置するかという別の質問につながりますか？私はデータを仮定します... Views私はUIに行くだろうが、ViewModelsまただろうか？ 最後に、ビジネスロジックをどこに埋め込むか。 CodePlex、DDD Exampleで以下を見つけましたが、いくらか助けになりましたが、Webアプリのように思えますが、それは問題ではなく、私の無知が輝いています。 誤解しないでください。フォルダをいくつでも持つことができ、好きな名前を付けることができます。私は、これらの場所が必ずしも呼ばれているものではなく、これがスケーラブルになるように、物を置く場所を見つけようとしています。 私の質問の核心はこのように示されるかもしれません。によって生成されたオブジェクト がありtblPersonます*.dbml。これは明らかであり、「データ」レイヤーに属します。 これで、Model、DTO、Domain Model、またはと呼ばれる別のLayer（project？）で呼び出されるものがありPersonます。私はどこに置くべきかわからないことのMapperためPersonに必要になるでしょうtblPerson。 次に、ViewModelをEditPerson取得しPersonます。たとえば、それから取得する独自のプロパティがありますが、それ以上の場合もあります。 最後に、そのViewModelにバインドされたビューがあります。 その段落が私の仮定と推測で満たされていることを明確にするために、誰かが私のために空気をきれいにするのを手伝うか、そこから洞察を提供してくれることを望んでいます。

17 .net  wpf  mvvm  domain-driven-design  project-structure 

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

17 .net  html5  wpf  silverlight  windows-8