問題タブ [domain-model]

ビュー モデルとドメイン モデルを混在させることは合理的ですか?

つまり、ビュー モデル オブジェクトにはいくつかのドメイン モデル オブジェクトが含まれます (その逆ではありません!)。

DTO 型がドメイン モデル内で作成され、型間で受け渡されていることがわかります。これは良い習慣ですか？

私は常に、DTO は主にコンテキスト境界 (オブジェクト グラフの端) で使用され、コンテキスト実装を分離する (ドメイン/UI 境界など) と考えていました。

ドメインモデルを作成するとき、ほとんどの場合、データベース内の対応するテーブルの主キー列を表すエンティティの Id フィールドまたはプロパティがあります。私の質問は、ドメイン モデルとは関係のないこのキー プロパティがある場合 (つまり、これは単なるデータベースの問題です。Martin Fowler は意味のないキーと名付けることを好みます)、永続化レイヤーがドメインにリークしているのでしょうか? もしそうなら、どうすればそれを防ぐことができますか？

ドメイン モデル タイプがあります。その多数のプロパティの 1 つは、戻り値を適切な言語に翻訳する機能を提供するために ITranslationService を必要とします。

ITranslationService をドメイン モデル型のコンストラクターに挿入する必要があります (そのため、型がインスタンス化されるすべての場所を変更する必要があり、NhIbernate を介して取得するときに初期化を考慮する必要があります)。多くのプロパティの); または、使用できる別の機能パターンはありますか?

誰かが共有できる関連する経験を持っていますか?

入力チェックをモデルから切り離し、他の場所、たとえばコントローラーで処理するのは良い習慣ですか？もしそうなら、MVCまたはDDDの観点からこれをどのように行うことができますか？

たとえば、ビジネス オブジェクトがありますPerson。

そして、このクラスのオブジェクトにデータ バインドされた Winforms UI コントロールがいくつかあります。

現在、変更を行っていますが、実装somePersonしたおかげでINotifyPropertyChanged、それらの変更が UI に反映されています。ここまでは順調ですね。

ここで私の問題:ワーカー スレッド (つまり、UI スレッドではない) に変更を加えるとsomePerson、たとえばバックグラウンド操作として DB からデータをロードしているために、データ バインディングが更新を試みるため、例外が発生する可能性があります。コントロールは、UI スレッドでのみ発生することが許可されています。

これは、UI 要素を呼び出して、ビジネス オブジェクトを更新できるかどうかを確認する必要があることを意味します。これは、アプリケーションの論理階層化に違反しInvokeRequiredているように思えます。

理想的には、ビジネス オブジェクトが UI にデータ バインドされているかどうかを気にせずに、ビジネス オブジェクトを変更できるようにしたいと考えています。これは、Winforms のデータ バインディングで何らかの形で可能ですか?

以下に示すドメイン モデルを検討してください (簡潔にするために簡略化されています - ID などはありません)。Aは一度だけCustomerコメントできProductます。Customerクラスが所有する s のコレクションを持つことができないと仮定しましょう (ここには入りたくない理由があります) Review。これProductがメインの集約ルートです。

多くの場合、この状況では、 を取得するときProductに、特定の のコンテキストでのみ取得されますCustomer。Reviewsつまり、その特定の に属するコレクションのメンバーのみに関心がありCustomerます。

では、オブジェクトを取得するときProductに、コレクションの人口をCustomer私が提供するレビューに制限する方法はありますか? これはNHibernateでどのように実装されますか? これは NHibernate のベスト プラクティス (および程度の低い DDD) とまったく一致していますか?

ありがとう

このエンティティをモデル化する最善の方法を見つけようとしていますが、行き詰っています。基本的なユースケース/ストーリーは次のとおりです。

機材が現場に到着。どんな機材かは、届くまでわかりません。機器が現場に到着したら、到着したこと、およびアイドル状態かアクティブ状態かを記録する必要があります。アクティブな場合、ユーザーは機器が実行した作業を記録する必要があります。機器がサイトを離れるときは、これに注意する必要があります。

サイトに機器があるかどうか、以前にサイトにあった機器などを簡単に照会できる必要があります。

私は日付の面で立ち往生しています。特定の日にアイドル状態とマークされていない場合、cronジョブを実行して機器をアイドル状態としてマークすることに頼らないようにしています。これを行う方法が必要なように感じます。これが私が思いついたものです：

アイデアは、Site.Equipment.Where(x=>x.Departure == null)どの機器がまだ現場にあるかを確認するようなクエリを実行できるということです。特定の日付に EquipmentUtilization がない場合は、アイドル状態であると見なされます。次に、DateTimeEnumerator をセットアップできます。

到着日から DateTime.Now または DepatureDate (null でない場合) までの日付のリストを作成します。何らかの理由で、これは醜いようです。DateTime 列挙子を Equipment オブジェクトの内部に配置する必要がありますか? これはすべて一緒にするか、別の方法で行う必要があるように感じますが、実行すると機能します。提案？

この例の「ルックアップ」IList<string>は州の略語です。通常、ドメイン モデル POCO にはこれらのオプションは含まれません。ViewModel は通常、元のドメイン モデルと Lookup オブジェクトの両方を参照してこの責任を負いますが、ドメイン モデルがネストされていて、MVC テンプレートを使用している場合はどうなりますか (元のモデルのルート プロパティにアクセスできないでしょうか?

テンプレートの 1 つのオブジェクトにルックアップを含め、別のオブジェクトにモデルを含める方法はありますか? ビュー内のそのテンプレートに固有のビューモデルをオンザフライでアセンブルすることは許可されていますか (そこからネストされたデータを含める必要があります)。ルックアップ値をプルダウンする静的メソッドは悪いと思います。

何か案は？

注（私の知る限り）：

リポジトリのドメイン モデル POCO の構造は変わりません。たとえば、1 つのモデルに Customer オブジェクトと米国州の DDL オプションの両方が必要な場合、通常、Customer オブジェクトと Customer Lookup リストを参照する ViewModel があります。

ただし、ネストされたドメイン モデル (集約ルート) がある場合、ネストされたオブジェクトにはルックアップ リストを配置する場所がなく、MVC テンプレートはルート レベルのビュー モデル (ビュー モデルは部分モデル) にアクセスできません。

編集：

ViewModel のルート レベルに DDL リストを配置し、Customer オブジェクトに到達したら、ルート レベルの DDL リストと現在の Customer オブジェクトを参照してテンプレートに送信する新しい ViewModel を作成する方法はありますか? これにより、モデル内の重複データが排除され、すべてのビューに対して単一のモデルが使用されます。唯一の悪い点は、ビュー内のコントローラーのようなデータ アセンブリ コードです (これも同様に悪いことです)。