問題タブ [domain-object]

Symfony2 に基づく私たちのアプリケーションでは、特定のドメイン オブジェクトに対する権限を持つシステム内のユーザーのリストを作成したいと考えています。私たちは ACL を使用しており、当面の本能は、問題のドメイン オブジェクトの ACLProvider から返された ACL オブジェクトを調べて、アクセス許可を持つユーザー (または少なくとも SecurityIdentities) を返すことができるメソッドを探すことでしたが、そのようなものは見つかりませんでした。メソッド。

この機能が API を介して利用できることは確かですが、これらのメソッドが隠されている場所を見つけることはできません。

EDIT代替手段は、acl-tablesでこれらの接続を直接検索してその方法を見つけることですが、それはあまりきれいではなく、おそらく車輪を再発明することになります.

WebアプリケーションでSymfony2のACL実装を使用する場合、ACLを使用するための提案された方法（単一のドメインオブジェクトに対するユーザーのアクセス許可をチェックする）が実行不可能になるユースケースに遭遇しました。したがって、問題を解決するために使用できるACLAPIの一部が存在するかどうか疑問に思います。

ユースケースは、テンプレートに表示されるドメインオブジェクトのリストを準備するコントローラーであり、ユーザーは編集するオブジェクトを選択できます。ユーザーにはデータベース内のすべてのオブジェクトを編集する権限がないため、それに応じてリストをフィルタリングする必要があります。

これは（他のソリューションの中でも）2つの戦略に従って実行できます。

1）オブジェクト（または複数のオブジェクト）の現在のユーザーのACLからの有効なオブジェクトIDを指定されたクエリに追加するクエリフィルター。すなわち：

2）完全なリストがデータベースから取得された後、ユーザーが適切な権限を持たないオブジェクトを削除するクエリ後のフィルター。すなわち：

最初の戦略は、データベースがすべてのフィルタリング作業を実行し、両方とも2つのデータベースクエリを必要とするため、望ましい方法です。1つはACL用、もう1つは実際のクエリ用ですが、これはおそらく避けられません。

Symfony2にこれらの戦略の1つ（または望ましい結果を達成する何か）の実装はありますか？

Transfer オブジェクトと Domain オブジェクトの違いを簡単に説明していただけますか? そして、Javaの例を挙げることができれば、それは素晴らしいことです..

アプリケーションへのインターフェースが 2 つあるとします。

• Web フロントエンド
• データを提供するバックエンド

どちらも Web サービスと通信し、その Web サービスはビジネス ロジックを処理し、オブジェクトを永続化する別のデータ レイヤーと通信します。

では、Web サービスの各クライアントがその Web サービスの DataContract を使用する場合、何のためにドメイン オブジェクトが必要なのでしょうか?

ドメイン駆動設計はここでどこに当てはまり、私のアーキテクチャにどのような利点をもたらしますか?

それとも、私がすでに持っているものは問題なく、ドメイン オブジェクトはまったく必要ないということですか?

ドメイン駆動設計の意味と目的を誤解していますか?

新しいシステムをゼロから構築し、アプリケーションの設計に取り組んでいます。ドメイン オブジェクトをモデル化するための実行可能なアプローチを検討しています。

プロジェクトに関するいくつかの詳細 - これは、ESRI ArcMap (GIS アプリケーション) に統合されたかなり大規模なデータ入力 WinForms アプリケーションになります。データ アクセスは、ArcMap 独自のデータ アクセス レイヤーを経由する必要があります。データは、カーソル スタイル アクセスを介して取得および保存されます。これはデータを取得する問題ではありませんが、私が知る限り、データベースと直接やり取りできないため、Entity Framework や NHibernate などの ORM ツールは除外されます。

WinForms アプリケーションは、MVP監視コントローラーパターンに従います - ビューはモデルにバインドされます。プレゼンターもモデルを変更します。したがって、Domain オブジェクトは以下をサポートする必要があります。

• 変更通知
• 追跡を変更します。最低限、モデルが変更されたかどうかを知りたいです。

これまでの私のオプション：

1. POCOS を手で書きます。+長所/短所:
   • +実行可能であるべき
   • +ビジネスロジックに対応可能
   • +バインド可能
   • ・手作業が多い
     • -INotifyPropertyChange インターフェイスを介した通知の変更。
     • -手動で維持する必要がある IsDirty プロパティによる変更追跡。
2. POCO によってラップされた ADO.NET DataSet。+長所/短所:
   • +変更通知「無料」
   • +追跡を「無料で」変更
   • +バインド可能
   • ・なんかゴチャゴチャした感じ

私が除外したこと：

• Entity Framework - 私は .net Framework 3.5 を使用しているため、Code First はサポートされていません。私の知る限り、ドメイン ロジックの処理は非常に面倒です (イベント ハンドラー)。

他に良いオプションはありますか？おそらくコード生成（ツールに関する提案はありますか？）、フレームワークですか？知恵の言葉、アドバイス？

GORM .getを使用してオブジェクトoを取得し、いくつかのフィールドを変更し、o.validate（）を呼び出して、HibernateがオブジェクトをDBに保存せずにエラーを見つけるにはどうすればよいですか？破棄自体は保存を妨げません。どちらもしません

この投稿では、コマンドオブジェクトの使用を推奨していますが、このコードは多くの異なるドメインオブジェクトに適用されます。Hibernateに保存しない命令を与える簡単な方法（検証するために渡されるいくつかのパラメーター？）が必要です。毎回新しいインスタンスを作成する必要がありますか？

このリンクでは、異なる通貨の資金を一緒に追加するための Money オブジェクトの関数について説明しています。

まず、Service Locator パターンを使用したくありません。私は現在、Money オブジェクト自体に変換を行わせないパターンを使用しています。異なる通貨を一緒に追加しようとすると、スローされます。

Money オブジェクト (つまり、MultiCurrencyAccount) を所有するオブジェクトで、Money の数学演算を処理します。私の問題は、現在 IMoneyConverter を MultiCurrencyAccount ドメイン オブジェクトに注入するコンストラクターであることです。IMoneyConverter は実際には IForeignExchangeService を使用するサービスであるため、これは私には汚いと感じます (これは DB にヒットする可能性があります)。抽象化を扱っているので、実装を気にする必要がないことはわかっていますが、奇妙に感じます。

私がベースから外れていて、ドメインオブジェクトにサービスを注入することが「正しい」のか、それともよりエレガントな方法があるのか​​ どうかはわかりません。

ユーザー インターフェイスでドメイン オブジェクトを直接使用する必要があるかどうかはわかりません。たとえば、ユーザー ID、名前、パスワード、および役割のリストを持つドメイン エンティティ ユーザー ユーザーのユーザー インターフェイスを設計したいと考えています。エンティティは、無効な状態にならないように設計されています (無効なパスワードや空のユーザー ID など)。

ユーザー インターフェイスを設計する最も適切な方法は何ですか?

1) ドメイン モデルに固執する: 3 つのウィンドウを設計します。ウィンドウ「新しいユーザー」は、指定されたユーザー ID、名前、およびパスワードで新しいユーザーを作成します。パスワードを変更するための別のウィンドウ「パスワードの変更」と、既存のユーザーの名前と役割を変更できる別の「ユーザーの変更」ウィンドウ

2) 1 つのウィンドウのみを使用して、指定された userId、名前、パスワード、およびロールのリストを持つユーザーを作成することが望ましい場合があります。userId をまだ入力していなくても、ロールを追加できるはずです。

オプション 1 は、ユーザー インターフェイスでドメイン オブジェクトを直接使用できるため、実装が最も簡単です。しかし、ユーザー インターフェースは使いにくいものになる可能性があります。オプション 2 が望ましいですが、ドメイン オブジェクトを直接使用することはできません。ユーザーがまだ作成されていない場合、ロールを追加する方法がわかりません。userId を表す一時的な空のテキスト ボックスなど、その時点で正しい情報がない可能性があるため、ユーザーを作成できません。どうすればこれを達成できますか？

私が考えることができる唯一のクリーンなソリューションは、実際のドメイン オブジェクトの情報を模倣するユーザー インターフェイスで使用するクラスを作成することです。したがって、空のユーザーを作成して役割を追加し、その後で userId を設定できます。ユーザー インターフェイスは、その情報を使用して実際のドメイン オブジェクトを作成できます。

これを回避する簡単な方法はありますか？これは通常どのように管理されていますか？

新しいエンティティに自動生成されたデータを入力したいと考えています。たとえば、エンティティ フィールドに一意のトークンを入力したいとします。これは、ドメイン オブジェクトのコンストラクターで実行できると考えています。

驚いたことに、Roo によって生成されたドメイン/エンティティ クラスのコンストラクタが見つかりません。自分でコンストラクターを導入することで、ガイドラインに違反することはありますか? それとも、代わりに MyClass_Roo_Entity.aj から永続性をプッシュして、そこで実行する必要がありますか? 前もって感謝します！

ドメイン オブジェクトは JPA エンティティと同じですか? 値オブジェクト (ドル紙幣など) がある場合、それを参照オブジェクトとしてデータストアに格納するにはどうすればよいでしょうか (または格納すべきでしょうか)。

場合によってはエンティティであり、他の場合では値オブジェクトであるドメインオブジェクトの微妙な点は何ですか? 誰か私にこれに関する良い論文を教えてもらえますか?