問題タブ [poeaa]

この質問は、Martin Fowler 著、Patterns Of Enterprise Application Architecture という本の特定の UML ダイアグラムに関するものです。

302 ページの「継承マッパー」クラス図で、Footballer MapperとBowler Mapperの間に「双方向の関連付け」があるのはなぜですか?

DBの人工主キーを「生成」するために別のテーブルを使用したことがありますか（およびその理由）。つまり、テーブル名と現在のIDの2つの列を持つテーブルを作成します。これを使用すると、テーブル名で行をロックし、キーの現在の値を取得してインクリメントするだけで、テーブルの新しい「ID」を取得できます。 1つずつ、行のロックを解除します。標準の整数ID列よりもこれを好むのはなぜですか？

PS「アイデア」は、エンタープライズアプリケーションアーキテクチャのファウラーパターンからのものです。

アプリケーションコンポーネントの継承マッパーパターンの実装を計画しています http://martinfowler.com/eaaCatalog/inheritanceMappers.html

必要な機能の1つは、ドメインオブジェクトが集約されたアイテムの大規模なリスト（他の10,000個のドメインオブジェクト）を参照することです。

したがって、集約ルートドメインオブジェクトから他のドメインオブジェクトに渡される、ある種の遅延読み込みコレクションが必要です。

（php）モデルスクリプトを整理するために、2つのフォルダーに保存しています。

しかし今、私は自分の遅延読み込みコレクションがどこにあるのか疑問に思っています。それは両方の層をまたぐようです。内部的には一種のデータマッパーであり、外部的にはドメインオブジェクトです。

ある場所に別の場所に配置するための提案/正当化はありますか？

• daccess=データアクセス
• DDD =ドメイン駆動設計パターン、EricEvans-本
• PoEAA =アプリケーションアーキテクチャパターンのパターン、MartinFowler-本

私は最近、 Unit of WorkクラスとData Mapperクラスの間の依存関係の解決に関する質問をしました。

PoEAA では、Martin Fowler が、これらの依存関係を管理するために分離インターフェイスを使用することを提案しています。私の質問は簡単です。実際にこのパターンを PHP で実装することは可能ですか、それとも Java インターフェイスに固有のものですか? 高低を検索しましたが、PoEAA 以外の場所でこのパターンへの参照を見つけるのは困難です。

しばらくの間、リポジトリ パターン (DDD および POEAA) を使用しています。しかし、私たちのチームメンバーの何人かは、それは単なる抽象化の余分なレイヤーであり、不必要であると主張しています. 彼らの議論にはいくらかの利点が見られます。最新の ORM ソリューション (NHibernate または EF) には、必要なものがほとんどすべて揃っています。このトピックに関する反論と、このような記事を検索して見つけました。では、リポジトリ パターンはやり過ぎですか?

LINQtoSQL自動生成エンティティを処理するリポジトリレイヤーがあります。これらは最終的に、表面上でドメインに適したタイプにマッピングされます。ここで、クライアントコードにさらに高度なクエリ機能を提供したいと思います。そのクライアントコードは、ドメインオブジェクトタイプについてのみ認識しています。

これをクエリオブジェクトパターン（Martin Fowlerのエンタープライズアプリケーションアーキテクチャのパターンで名前が付けられている）で実装したいのですが、クライアントコードがドメインタイプでラムダ式を使用できるようにします。裏で、ドメイン対応のラムダ式をデータベース対応のラムダに変換し、この変換された式をリポジトリに送信して、LINQtoSQLを使用してデータベースに対して実行したいと思います。

私は現在、クライアントのマッピング機能を単純なプロパティに制限する貧乏人の実装を持っていますが、それをもう少し洗練されたクエリに開放したいと思います。AutoMapperやその他の既存のマッピングツールを使用してこれにどのようにアプローチするかはわかりません。また、OTTOMHが自社開発のコードを使用してこれを行う方法もわかりません。

これが私が望む種類の機能です：

このようなものを機能させるという究極の目標を持って：

私の質問は本当にこれだと思います：

1. そのようなマッパーを作成することは可能ですか？もしそうなら...
2. AutoMapperのようなツールでそうすることは可能ですか？もしそうなら...
3. すでに相互変換されているAutoMapperマッピングを利用することは可能ですかDomainType、DataEntityTypeまたは明示的にマッピングQuery<DomainType>する必要がありQuery<DataEntityType>ますか？

最終的には、必ずしも単純なオブジェクトプロパティではない任意のマッピング関数を柔軟に使用できるようにするためにこれを実行したいと思います。

エンタープライズ アプリケーション アーキテクチャのパターンという本を読んでいます。レジストリ パターンなどの基本的なパターンを調べているうちに、2002 年 11 月に最初に公開されたこれらのパターンが最適なソリューションではない可能性があることがわかりました。

たとえば、レジ​​ストリ パターンを取り上げます。私たちの組織では、db 操作に単純な JDBC 呼び出しを使用し、必要に応じて単一のトランザクションの接続オブジェクトを渡します。このアプローチは最適ではありませんが、依存関係が表示されないため、レジストリ パターンを使用する代替手段も適切とは言えません。テストの問題になる可能性があります。この動作を実装するためのより良い方法として、依存性注入が提案されています。

Java EE の Web/エンタープライズ アプリに携わったことのある方は、これについてコメントしていただけますか? また、各パターンの使用法を分析するために何をお勧めしますか (その長所と短所は?)。これについて詳しく説明している最近の本はありますか?

Martin Fowler の Patterns Of Enterprise Application Architecture と Front Controller のパターンを考えてみましょう: http://martinfowler.com/eaaCatalog/frontController.html どうやらシングルトン パターンを使用しているようです。さて、私は連携して動作する PHP アプリケーションのクラスのパッケージ (Zend のコントローラー パッケージなど) を持っており、それらをすべて使用可能にする 1 つのクラスがあり、フロント コントローラーの概念の多くに似ているため、PackageName_Front という名前を付けました。しかし、(Front Controller とは対照的に) シングルトン クラスであってはなりません。そうでない場合、私はそれを何と名付けますか？これは非常に大きなパッケージであるため、他の開発者が読みやすいように (独断的な方法ではなく) 可能な限り慣習に従う必要があります。

詳細: コントローラーに関連するものではありません。これは Zend_Form のように機能する単なるオブジェクトです (Zend_Form_Element_X や Zend_Validate などの他のすべてのオブジェクトの使用を 1 つのオブジェクトに統合します)。それは PackageName_Something でなければなりません。たぶん「ハンドラー」?...誰かがその名前を読んだときに、パッケージ全体での役割について混乱しないようにしたいだけです:)

私は大学で「ソフトウェア パターンと設計」のコースを行っており、コースの本は「エンタープライズ アプリケーション アーキテクチャのパターン - ファウラー」です。

水曜日にテストがあり、先生は過去のテストを持っていないので、テストがどのようになるかを確認することができます.

この本のコースを受講したことがあり、テスト前に実行できるテスト問題を持っている人はいますか?

私は POEAA のアーキテクチャ パターンの章を読んでいますが、Fowler は次のように述べています。 . ドメイン ロジックを小さなクラスに分割すると、ドメイン クラスとテーブルの 1 対 1 の一致が失敗し始めます. リレーショナル データベースは継承を処理しないため、戦略 [Gang of Four] やその他のきちんとした OO パターンを使用することが難しくなります. . ドメイン ロジックが複雑になるにつれて、データベースと常に対話することなくテストできるようにする必要があります。」

私はこれを本当に理解していませんでした。「ドメイン クラスとテーブルの 1 対 1 の一致」とは、関連付けや単一のテーブル継承階層がないクラスに対してのみという意味ですか?

また、ドメイン ロジックを小さなクラスに分解すると、パターンが失敗するのはなぜでしょうか?