問題タブ [architectural-patterns]

エンタープライズ アプリケーション アーキテクチャのパターンで、Martin Fowler は、ドメイン ロジックを編成するための 2 つのパターン、ドメイン モデルとサービス層について説明しています。ドメイン モデル パターンは「純粋な OOP」アプローチであり、モデル (おそらく ORM を使用してデータベースから検索されるオブジェクト) にビジネス ロジックが含まれます (ただし、おそらく別のクラスのロジックに委譲するだけです)。

サービス層パターンはドメイン モデル パターンに似ていますが、その前に実行可能なビジネス オペレーションを含む薄い層があります。MVC では、コントローラーは主にサービス層と対話します。適切に設計された MVC Web アプリケーションのほとんどは、このパターンを使用していると思います。

さて、私の質問に。Martin は、ドメイン モデル アプローチはよりオブジェクト指向のアプローチであり、したがってより優れていると示唆しています。私の経験では、実際に実装するのは非常に困難です (不可能を参照)。

上の最初の図の例を見てください。2 つの「エンティティ」ContractとがありProductます。これらは、マッパーを使用してデータベースに永続化されます。例では、 がありRecognitionStrategyます。Martin は、実際のビジネス ロジックを含むこの戦略に委任するためのメソッドをエンティティ自体に配置します。contract.calculateRecognitionsクライアントは、またはを使用してこの計算を実行しますcontract.recognizedRevenue(someDate)。同様の設計を実装する場合、通常、クライアント インターフェイスをstrategy.calculateRecognitions(contract)およびとして記述しますstrategy.recognizedRevenue(contract, someDate)。これにより、戦略と契約を調整するためにサービス層が必要になります。使用される具体的な戦略がサービスに注入されます。

マーティンのアプローチは、デザインの観点からは間違いなく魅力的ですが、セットアップを回避する作業ははるかに困難です。

1. a をインスタンス化するときに戦略を渡すのはProduct面倒です。使用する具体的なサービスでカリー化されたファクトリを介してを作成する必要がありますProduct。これにより、作成時にエンティティに渡されます。
2. データベース アクセスに対するきめ細かい制御ができません。ORM の設定によっては、 へのContract委任がProductごとにクエリを実行する場合がありますProduct。Productマッパー (または ORM) に s を貪欲にロードすることは、 をロードするContractが を呼び出すつもりがない場合、熱心すぎるかもしれませんcontract.calculateRecognitions()。私のアプローチでは、サービスがデータベース抽象化レイヤーの知識を持っているため、よりきめ細かい制御が可能になりますが、エンティティはそうすべきではありません。

ここに列挙していない問題点が実際にはもっとあると確信しています。

Martin のアプローチには、純粋なデータ モデル パターンを使用するよう説得する具体的な利点は何ですか?

C# winforms で MVP パターンを使用して、複数のテーブルからビューにデータを表示するにはどうすればよいですか?

次のテーブルがあるとします。

1. フルーツ

2. 色

   /li>

次に、私のソリューションでは、各テーブルのクラス、つまり Fruit クラスと Color クラスを作成し、独自のゲッターとセッター、およびデータベース内のテーブルを表すその他の詳細を持っています。

次に、Fruit と Color の 2 つのモデルも作成しました。

したがって、Color に関するレコードを表示するビューを作成する場合は、Color 用に作成したモデルを使用して、色のコレクションを取得します (例: List<Color>)。そのレコードを表示するために DataGridView を使用している場合、次のようなものが得られます。

Fruit レコードについては、上記と同じ方法を使用できますが、次のように色 ID の代わりに色名を表示する必要があります: (DataGridView またはカスタム コントロールを使用していると仮定します)

別のクラスを作成して「FruitColor」という名前を付け、上記の Fruit クラスと同じプロパティを与えることができると考えましたが、色 ID プロパティを持つ代わりに、代わりに色名に置き換えます...しかし、私は 'それが MVP での正しいやり方かどうかはよくわかりません。正しいやり方のヒントを皆さんに尋ねるべきだと思いました...

手動で行う方法を理解したいので、プロジェクトにORMを使用していません...しかし、ORMの使用に関連するヘルプもいただければ幸いです。また、3 週間前に MVP について学び始めたばかりなので、何か助けてくれることを本当に望んでいます。

2 つのオブジェクト、つまりFruit' andColor` があり、それらの定義は次のとおりです。

Fruit (e.g. List<Fruit>)コレクションをDataGridViewにバインドするにはどうすればよいですか? 結果の出力は次のようになります。

以下の出力とは異なります: (注: の NN.Colorはオブジェクト Color の名前空間を示します)

更新＃1： SOで
同様の投稿を見つけ、その投稿でいくつかの提案を試みましたが、機能していません...

私はリポジトリと作業単位パターンの実装に取り​​組んでいます。ただし、作業単位をコントローラーに配置してコントローラーにビジネスロジックを配置する代わりに、このロジックを分割するリクエスト/ハンドラーを実装しています。作業単位を分割し、リクエスト/ハンドラーを介してコントローラーにアクセスさせることにマイナス面はありますか? 以下のコード例を参照してください。

汎用レポ:

作業単位:

次に、モデルごとにリクエスト/ハンドラーを作成し、そこで Unit of Work をインスタンス化します。

コントローラーはリクエスト/ハンドラーにアクセスします。

注: 作業単位インスタンスをインスタンス化する複数の要求/ハンドラーが存在します。作業単位の目的はコンテキストを 1 つのインスタンスに保持することであるため、これにより問題が発生する可能性はありますか?

フィードバックをお寄せいただきありがとうございます。

私のコードには、この署名 (params + 戻り値の型) を持つ多くの関数があり、それらはすべてこの同じtry-catch句を使用しています。

さて、これは何度も何度も複製されており、複製が悪いことを知っています。これが発生する理由は、コードで複数を返すことができるようにしたいのですが、HttpStatusCodeResultそれを行うより良い方法がわからないためです。

この例では、内部サーバー エラーと OK の回答を返します。しかし、別の種類のエラーを返したい場合はどうすればよいでしょうか?

コード内で、レプリケーションなしで動作するモジュラーな方法はありますか? 使用できるデザインまたはアーキテクチャ パターンはありますか? もしそうなら、どれですか？

私はこれら 2 つのパターンに頭を悩ませようとしていますが、類似点と相違点について疑問に思っています。どちらも段階的なプロセスを使用しているように見えるので、私には似ています。誰かがこれらの 2 つのパターンにもう少し光を当てることができますか? パイプとフィルターのパターンは大規模なアプリケーションで使用され、ビルダーのパターンは小規模なアプリケーションで使用されるというのは正しいですか? 少し先に進みますが、ビルダー パターンでは、すべてのステップが同時に行われますか。つまり、完成したオブジェクトが返される前にビルダーに渡されるすべての属性ですか?

ありがとう。