問題タブ [domain-model]

リッチ ドメイン モデルを使用する利点を示す簡単な例を探しています。理想的には、前後のコード リストが必要です (できるだけ短くする必要があります)。

前のコード リストは貧弱なドメイン モデルと多くのかなり手続き型のサービス層コードを使用して解決された問題を示し、後のコード リストは豊富なオブジェクト指向ドメイン モデルを使用して解決された同じ問題を示す必要があります。

理想的には、コード リストは Java または Groovy である必要がありますが、かなり似たもの (C# など) であれば何でもかまいません。

やあみんな - これはZend FrameworkまたはMVC全般に関する質問です:

ビジネス オブジェクト (ユーザー、チームなど) を自分のビューにプッシュするのが良い考えなのか、配列などのダンプ データ コンテナーをレンダリング用のビュー。

ビューにビジネス オブジェクトをプッシュするとき、ビューとドメイン モデルの間の結合がより緊密になりますが、ビューは foreach($this->team->getUsers() as $user) { ... のようなことを簡単に実行できます。個人的にはとても便利だと思います。

ドメインモデルデータをダム配列で提供することは、より堅牢で柔軟に見えますが、ビューが実際のオブジェクトを操作できないため、オブジェクトのメソッドを使用して関連データにアクセスできないというコストがあります。

どうやってそれを処理しますか？

どうもありがとう、マイケル

私がやろうとしているのは、Plain Old PHP Object を使用してドメイン モデルを作成することです。すべてのインフラストラクチャを実行するライブラリを作成しています。だから私のモデルの1つはこのように見えます

新しいプロジェクトを作成setTypeし、有効な Type オブジェクトで呼び出し、ORM を使用してプロジェクト インスタンスを保存すると、プロジェクトとタイプの両方が保存されます。しかし、その後、プロジェクトをロードし、getTypeメソッドを使用して、ORM がこのメソッドを透過的に変更して、永続性からオブジェクトをロードするようにします。したがって、この方法は次のとおりです。

透過的に次のように変更されます。

アウトレット PHP は eval を使用して Project_Proxy という Project の Proxy クラスを作成しますが、Project のサブクラスが存在する場合があるため、方法があれば Reflection API を使用して解決策を探しています。

Googleで検索しましたが、メソッドの動作を変更する方法が見つかりませんでした

編集:または、Outlet PHP の eval メソッドを使用して、モデルとそのすべてのサブクラスのプロキシ クラスを作成することをお勧めしますか?

Product と Payers のコレクションを取得しました。支払人は、3 つの異なる方法で製品の支払いを行うことができます。ただし、パーセンテージを手動で設定するか、支払人の収入によって、または支払人のそれぞれの保有額によって支払います。製品の支払い方法は、製品の列挙型によって決定されます。

私の永続層では、Product、Payer、および ProductManuallyPaid の 3 つのクラスを取得しました。これは、Product が手動で支払われる場合、Product と Payer の間の多対多のクラスであり、各 Payer が支払わなければならないパーセンテージを指定します。

これをどのようにビューにマッピングすればよいですか? 新しい多対多クラス (支払人への参照、製品への参照、および支払人が支払うべき正確な金額で構成される) が必要ですか?

計算はサービス レイヤーで行う必要があると思いますが、サービス レイヤーは新しい多対多クラスが付加された製品/支払者の ViewModel/DTO バージョンを返す必要がありますか、それとも後で処理する必要がありますか? 後で処理する必要がある場合、エンティティにはその新しい多対多クラスのリストを含める必要がありますが、永続化レイヤーでは無視されますか?

エンティティ フレームワーク (.NET Framework 3.5 SP1) によって生成されたエンティティとカスタム ドメイン モデル クラスとの間の自動マッピングを取得するにはどうすればよいでしょうか。2 つの世界の間でオブジェクトを相互に変換するデータ コンバーターを作成できることはわかっていますが、これを自動的に行うにはどうすればよいでしょうか?

エンティティ フレームワークによって自動的に生成 (および更新) されたエンティティ クラス内では使用できないValidation application blockの検証属性でそれらを装飾し、ドメイン モデル クラスの開発を開始しました。したがって、自動的に、または少なくとも最小限の記述コードで、EF とドメイン モデルの間のマッピングが必要になります。

エンティティ：チーム<->TeamEmployee<->従業員

要件：

• チームと従業員は、対応するものがなくても存在できます。
• Team-TeamEmployeeの関係では、チームが責任を負います（親） [後でTeamRepositoryを使用]。
• Employee-TeamEmployeeの関係では、従業員が責任を負います（親） [後でEmployeeRepositoryを使用します]。
• 複製は許可されていません。
• 従業員が別のチームに属していない場合、チームを削除すると、チーム内のすべての従業員が削除されます。
• チームに従業員が含まれていない場合、従業員を削除すると、チームのみが削除されます。

マッピング：

従業員とチームの作成：

この後、transaction.Commit（）を使用して変更をコミットします。最初の奇妙なことは、チームと従業員を1つだけではなく、保存する必要があることです（なぜですか？！）。すべてのチームまたは（Xor）すべての従業員のみを保存すると、TransientObjectExceptionが発生します。

「オブジェクトは保存されていない一時インスタンスを参照しています-フラッシュする前に一時インスタンスを保存してください。タイプ：Core.Domain.Model.Employee、エンティティ：Core.Domain.Model.Employee」

作成したすべてのチームと従業員を保存すると、すべてが正常に保存されますが、リレーションテーブルTeamEmployeeには重複した関連付けがあります。

したがって、4つの関係の代わりに8つの関係があります。左側に4つの関係、右側に4つの関係。：[

何が間違っていますか？

その他の質問：チームまたは従業員を削除する場合、オブジェクトモデルのTeamEmployeeリストからチームまたは従業員を削除する必要がありますか、それともNHibernateが（session.delete（..）を使用して）私に代わって仕事をしますか？

Active Directoryにいくつかの変更（グループからのユーザーの追加/削除、ユーザーの属性値の変更など）を行うアプリケーションがあります。

現在、それを再設計中です（「スパゲッティコード」からより階層化されたソリューションへ）。Active Directoryの管理機能は、ドメインレイヤーである程度抽象化したいものですが、同時に、ほとんどの機能はテクノロジに大きく依存しています。

すべてのActiveDirectoryアクセスコードをDBアクセスとともにデータアクセス層に配置する必要がありますか、それとも関数のActive Directoryライブラリを作成し、ドメインモデルからこのライブラリを直接呼び出すことは問題ありませんか？それはドメインオブジェクトを永続的に認識させます、そしてそれはおそらく悪い考えですか？

または、すべてのActive Directoryアクセスを代わりにサービス層で実行し、ドメイン層を含まないようにする必要がありますか？

Microsoft TFS (チーム ファウンデーション サーバー) のドメイン モデル (情報モデル) を見た人はいますか? それはどこにありますか？他の製品と統合する機能を理解する必要があります。

複数の状態を持つことができる、タスクに相当するエンティティがあります。「タスク」は、保留中、合格、または失敗のいずれかの状態になります。これらの各状態には、いくつかの固有のデータもあります。たとえば、失敗した状態では、エンティティには失敗の理由が必要であり、保留中の状態では、評価の期限が必要です。

上記のことから、各状態を表す個別のオブジェクトが必要であると考えるようになりましたが、エンティティの基になる ID は同じままにする必要があるため、これを単一のオブジェクトと考える方向に後退しました。

また、状態から状態への遷移にはいくつかのロジックが必要です。「合格」状態に遷移する「保留」タスクは、同じ遷移を行う「失敗」タスクとは異なる方法で処理されます。

各状態の表現がまったく同じである場合は、プリミティブ プロパティを使用するだけで済みます。ただし、州ごとに表現がわずかに異なるため、これをモデル化する最善の方法を見つけるのに苦労しています。内部状態を管理するためのロジックがややこしくなってきているので、一歩下がって再考することにしました。何かご意見は？

私はこの言語にとらわれないと考えていますが、私はc＃を使用しています。

抽象リポジトリを使用してドメインオブジェクトをロードする永続性のないドメインモデルがあります。私のリポジトリ（データアクセス層（DAL））の具体的な実装では、エンティティフレームワークを使用してSQLサーバーデータベースからデータをフェッチします。データベースには、そのvarchar列の多くに長さの制約があります。ここで、次のドメインクラスがあると想像してください。

そして、次のように定義された抽象リポジトリ：

sqlserverのテーブルの[text]列は次のように定義されますnvarchar(100)

ドメインクラス（ ）は永続性を無視していると述べましたが、エンティティフレームワークが例外をスローするため、具体的なリポジトリの実装では最終的に保存できないパラメータCaseの値を許可するのは間違っていると感じています。textの割り当てtext100文字を超える場合、エンティティフレームワークで生成されたクラスのプロパティ。そこで、ドメインモデルでこの制約をチェックすることにしました。これにより、データをDALに渡そうとする前にデータの有効性をチェックできるため、エラーレポートがドメインオブジェクトに対してより中心的になります。コンストラクターとプロパティセッターで制約を確認するだけでよいと主張できると思いますが、同じような制約を持つクラスが何百もあるので、問題を解決するためのより一般的な方法が必要でした。

さて、私が思いついたのは、ConstrainedString次のように定義された、というクラスです。

ConstrainedStringさらに、私は呼び出されたの実装を持っていますString100：

したがって、その別の実装につながると、次のCaseようになります。

さて、私の質問は; いくつかの組み込みクラスまたは代わりに使用できる他のアプローチを見落としていますか？それとも、これは合理的なアプローチですか？

コメントや提案は大歓迎です。

前もって感謝します