問題タブ [domain-object]

私は次のモデルを持っています：

私は次のコントローラーを持っています：

ビュー内のモデル配列にアクセスするにはどうすればよいですか? モデルに直接アクセスする方法はありますか、または次のようにプロパティを割り当てる必要がありますか?

意見：

上記の問題は、ユーザーが次のように変更できることです。

私の販売モジュールにはクラスがOrderあり、そのクラスはいくつかの分類目標に使用し、s にいくつかのビジネス ルールを適用します。各クラスには独自のテーブルがあります。OrderTypeOrderTypeOrder

DDDプロジェクトにテクニックを適用したい。Orderでは、はAggregation rootだと思いますが、どうOrderTypeでしょうか? Order集計にも含まれていますか、それともValue オブジェクトですか? 価値ある物になると思います。私は正しいですか？

これは明確な答えがある質問ではありませんが、私のアーキテクチャについてアドバイスが必要です。このトピックについては、さまざまな意見があるかもしれません。

アーキテクチャを愚かなエンティティから豊富なドメイン オブジェクトに移行しようとしています。現在のバージョンでは、ビジネス ロジックを表す読み取り専用のプロパティとメソッドを持つ抽象ドメイン オブジェクトがあります。

それらから派生して、永続エンティティへのマッピングを実装し、保存ロジックを実装します。

これは非常に簡単に機能します。パブリック セッターがなく、ドキュメントとのマッピングであってもテストできるため、プロジェクトは常に有効です。

しかし、私はいくつかの問題にも気付きました:

1. 私はいつもいくつかのプロパティをマッピングするのを忘れていました.MongoProjectに何をシリアル化する必要があるかを伝える方法はありません.
2. プロジェクトが複雑な集約ルートである場合は特に、save メソッド内で何が変更されたかわからないため、マッピングの実装が比較的複雑になることがあります。私の状況では、mongodb で永続性を実装するのは非常に簡単でしたが、エンティティ フレームワークでは悪夢でした。

アプリケーションの永続性をどのように解決しますか?また、マッピングの問題に対する他の解決策はありますか?

私は ZendFramework 1.1 を利用したアプリケーションを 2 年間にわたって開発してきましたが、新しいことを学んだり試したりするために、リファクタリングのいくつかの異なる段階を見てきました。現在の状態では、私の構造は、物事を迅速に完了できるという点でかなり優れていると感じていますが、肥大化してぎこちない依存関係がたくさんあると感じている特定の領域でいくつかの改善を使用できることは確かです.

私のアプリケーションからサンプルコードをいくつか書き出すので、ここで我慢してください。保存する必要があるインスタンスをOrder持つオブジェクトの例を使用します。OrderItemインスタンス化と保存に必要なすべての部分を説明します。

私の理解が及ぶ限り、ここで行っていることは、 Domain ModelsよりもActiveRecord設計パターンに沿っていますが、両方の慣行があると思います...

データの解析、保存、およびすべてのモデルに適用されるほとんどすべての機能 (より適切な用語はエンティティかもしれません) は、次のように BaseObject に存在します。

基本DataMapperクラスには、オブジェクトごとに定義されているため、オーバーロードされることsaveのない、insertおよびの非常に単純な実装があります。これは少し不安定な気がしますが、うまくいきますか？の子クラスは、基本的にドメイン固有のファインダー機能を提供するだけです。update$schemaBaseMapperlookupOrderByNumberfindUsersWithLastName

私が持っているものは必ずしもひどいものではないように感じますが、ここにはあまり良くないデザインがいくつかあるようにも感じます. 私の懸念は主に次のとおりです。

モデルは、データベース テーブル スキーマに密接に結合された非常に厳格な構造を持っているため、モデルまたはデータベース テーブルからプロパティを追加/削除するのは非常に面倒です! $tableデータベースに保存するすべてのオブジェクトを$mapperコンストラクターで指定するのは悪い考えだと思います...どうすればこれを回避できますか? を定義しないようにするにはどうすればよい$schemaですか?

検証は、データベースの列名にも対応するモデルのプロパティ名に非常に密接に結び付けられているため、少し奇妙に思えます。これにより、データベースやモデルの変更がさらに複雑になります。検証のためのより適切な場所はありますか?

DataMappersは、いくつかの複雑な検索機能を提供する以外に、実際にはあまり機能しません。複雑なオブジェクトの保存は、オブジェクト クラス自体によって完全に処理されます (たとえば、Order私の例ではクラスです。「複雑なオブジェクト」以外に、このタイプのオブジェクトを表す適切な用語はありますかOrder?OrderItemまた、保存する必要があるオブジェクトDataMapper は、現在Orderクラスに存在する保存ロジックを処理する必要がありますか?

お時間とご意見をお寄せいただきありがとうございます。

集約ルートと子エンティティを持つドメイン駆動設計を使用しています。

集約不変条件は、集約ルートConfigurableServiceメソッドを介して強制され、子エンティティのメソッドに連鎖し、グループ間の要件をマップするリストGroupsを使用します。Dependencies

不変の例の 1 つConfigurableServiceは、SkuId がリスト内のいずれかのグループに含まれている場合にのみ、依存関係を作成できるようにすることです。

私が行ってグループまたは依存関係を公開すると（mongodbが永続性を必要とするため）、このドメインロジックをバイパスできます-したがって、以下のようなエンティティメソッドを呼び出すパブリックプロパティでクラスを展開できると考えましたDependenciesおよびGroupsプロパティ：

これはドメイン ロジックをチェックするため、永続化する必要がある内部プロパティごとに繰り返します。

これは、プロパティが正しい順序で設定されている限り、オブジェクトがビルドされたときにリポジトリから読み取るときに正常に機能します...たとえばDependencies、例外をスローする前にグループが設定された場合 (SkuID は存在しません)。

質問

1. 不変条件を保護し、Mongodb がドメイン エンティティ オブジェクトを永続化/取得できるようにするための推奨される方法は何ですか?

2. mongodb がデータベースからハイドレートするときにプロパティが設定される順序を制御できますか?

3. または、カスタムのシリアル化メソッドを作成するのが最善でしょうか (どうすればよいですか)?

Orderドメイン クラス ( ) と、hasMany = [items: Item]のインスタンスを編集できる編集画面がありますOrder。

編集画面には、追加/削除されたtotalCostajax 経由で計算されるフィールドがあります。itemsのバックエンド計算totalCostは複雑で (フロントエンドでは実行できず、バックエンドで実行する必要があります)、以下に依存します。

• 編集画面での保存されていない変更の状態
• order編集画面自体にない編集中のプロパティ

したがって、totalCost計算を実行するには、次のようにします。

ajaxCalculateTotalCost()これに関する問題は、編集中のインスタンスに対して ajax 呼び出しが行われるOrderと保存されることです。私が理解している限り、Spring または Hibernate は HTTP リクエストの最後にセッションをフラッシュしますか???

これは、ユーザーが追加/削除したかのように、フォームの下部をitemsクリックして変更をキャンセルできない場合の問題です ( ajax 呼び出しが発生したときに保存されます)。CancelOrder

Orderインスタンスを保存せずに計算を実行する方法を誰かが提案できますか?