問題タブ [poeaa]

古典的な「デザイン パターン: 再利用可能なオブジェクト指向ソフトウェアの要素」は、実際に私たちのほとんどにデザイン パターンのアイデアを紹介しました。

しかし、最近では、Martin Fowler 著の「Patterns of Enterprise Application Architecture」(POEA) などの本が、日常の仕事ではるかに役立つことに気づきました。

仲間の開発者との議論では、.NET のようなフレームワークが GOF 本の多くのパターンをゆっくりと提供し始めていることを (公正な) 指摘する人が多いのに、なぜ車輪を再発明する必要があるのでしょうか?

多くの開発者は、GOF の本がデザイン パターンに関する唯一の参考資料であると考えているようです。彼らの論理は、フレームワーク (.NET など) が多くの GOF パターンを提供しているため、パターンは彼らの時代を迎え、もはやそれほど重要ではなくなったということです。

驚いたことに (少なくとも私にとっては)、POEA で説明されているパターンについて言及すると、しばしば空白の視線に遭遇します。

POEA は、パターンが単なる Interators、Singleton、Command などではないことを証明しています。また、GOF のパターンは、実際にはパターンの別個の「カテゴリ」にすぎず、それらとは異なる (重複しない) レベルの設計に適用できるとも言えます。 POEAで。

では、他のどの「カテゴリ」のパターンがあなたの開発に適用されましたか? これらのパターンはどのレベルの設計に適用されますか? 通常、開発プロセスのどの時点で使用されますか? これらのパターンに関する本や参考文献はありますか?

私は小さなプログラムを書いています。作成された各リポジトリを制御するために作成しているインターフェイスは、Save（IPublicObject）のメソッドを定義します。リポジトリCRUDのSQLバージョンにLINQを使用しています。私の質問はこれです。インターフェイスタイプを受け入れるメソッドを1つだけにしたい。次に渡す継承されたタイプの保存アクションを見つけるのに最適な方法を考えたいと思います。

この本では、エンタープライズアプリケーションアーキテクチャのパターンを読んでいます。継承マッピングに頼っています。だから私はの派生オブジェクトを作成します

次に、これをリポジトリの保存関数に渡します。この時点で、私はどのように言うのが最善かを考えようとしています。「何を」を使用する必要があります。保存方法など...

タイプをマッピングするレジストリ、構成設定を使用する必要がありますか？

エンタープライズ アプリケーション アーキテクチャのパターンで、作業単位は単一のセッションでのみ使用する必要があることを読みました。したがって、各セッションには唯一の作業単位が必要です。アプリケーション全体 (私の場合は ASP.NET) に対して 1 つの作業単位を使用できなかった理由を教えてください。

私は現在、ドメイン層からデータベースを完全に抽象化する Data Mappers を使用するアプリケーションの書き直しに取り組んでいます。ただし、 Domain オブジェクト間の関係を処理するためのより良いアプローチはどれか疑問に思っています。

1. 関連するデータ マッパーから必要な find() メソッドをドメイン オブジェクト内で直接呼び出します。
2. リレーションシップ ロジックをネイティブ データ マッパーに記述し (これは、例が PoEAA で行う傾向にあります)、ドメイン オブジェクト内でネイティブ データ マッパー関数を呼び出します。

「Fat Model、Skinny Controller」というマントラを維持するために、ドメインオブジェクトはデータマッパーを認識している必要があるように思えます（それが独自のものであるか、システム内の他のマッパーにアクセスできるかどうか）。 . さらに、オプション 2 は、単一のデータ マッパーに限定するのではなく、複数のデータ マッパーにまたがるテーブル アクセス ロジックを作成するため、データ アクセス レイヤーを不必要に複雑にしているようです。

では、ドメイン オブジェクトに関連するデータ マッパーを認識させ、ドメイン オブジェクトから直接データ マッパー関数を呼び出すのは正しくないのでしょうか?

更新:これらは、ドメイン オブジェクト間の関係の問題を処理するために思い描くことができる唯一の 2 つのソリューションです。より良い方法を示す例は大歓迎です。

Martin Fowler の「Patterns of Enterprise Application Architecture」を購入しようと考えています。

私が見る限り、これは素晴らしい本のように思えます。エンタープライズ Java に偏ったアーキテクチャーの本であり、まさに私が必要としているものです。

しかし、コンピュータ時代では、かなり古いです。2003 年は遠い昔のことで、その時から物事はかなり進んでいます。

この本は今でも関連性があり、読む価値がありますか?

エンタープライズアプリケーションアーキテクチャのパターンで、MartinFowlerは次のように書いています。

したがって、この本は、エンタープライズアプリケーションをレイヤーに分解する方法と、それらのレイヤーがどのように連携するかについて説明しています。ほとんどの重要なエンタープライズアプリケーションは、何らかの形式の階層化アーキテクチャを使用しますが、状況によっては、パイプやフィルターなどの他のアプローチが役立つ場合があります。私はそのような状況には立ち入りません。代わりに、階層化アーキテクチャが最も広く役立つため、そのコンテキストに焦点を当てます。

非階層化アプリケーション/アプリケーションの一部を構築するためにどのようなパターンが存在しますか？金融機関の統計モデリングエンジンを利用してください。データアクセス用のレイヤーがあるかもしれませんが、ほとんどのコードは単一のレイヤーにあると思います。そのようなレイヤーにGangofFourのパターンが表示されることを期待しますか？ドメインモデルはどうですか？OOを使用しますか、それとも純粋関数型ですか？

引用では、レイヤーの代替モデルとしてパイプとフィルターについて言及しています。データ処理を分解する方法としてパイプを使用するこのようなエンジンは簡単に想像できます。他にどのようなパターンがありますか？タスクのスケジューリング、結果の集約、作業の分散などの分野に共通のパターンはありますか？MapReduceの代替手段は何ですか？

著書「エンタープライズ アプリケーション アーキテクチャのパターン」で、Martin Fowler は、ソフトウェア開発、特に ORM に関連して一般的に見られる永続化パターンについて語っています。

Hibernate が最も厳密に準拠しているパターンはありますか?

ファウラー PoEAA p. 498 null-object パターンを次のように定義します (サンプルは短縮されています。言語は c# ですが、問題ありません)。

INullマーカーインターフェイスとして使用されます。私は次の 3 つの理由から、このアプローチがあまり好きではありません。

1. プロパティは仮想としてマークする必要があります
2. エンティティ クラスを封印できなくなりました
3. 少なくとも (n+1) 個の新しい型が導入されています (n 個の null オブジェクト、1 個のマーカー インターフェイス)

なぜこのように実装されていないのですか：

一般的に、Fowlers の例はすべてよく考えられていることがわかりましたが、ここで見落としているものがあることは明らかです。