4

ビジネスロジック/サービスレイヤーに配置するか、部分クラス機能を利用する拡張ドメインクラス（EF T4で生成されたPOCO）の新しいメンバーに追加できるビジネスロジックがあります。

だから私は持つことができます：

a）bool OrderBusiness.OrderCanBeCancelledOnline(Order order)..または（IOrder注文）

また

b）bool order.CanBeCancelledOnline()..つまり、注文自体がキャンセルできるかどうかを知っています。

私にとってオプションb）はもっとOOです。ただし、オプションa）を使用すると、他のドメインオブジェクトやサービスを使用するなど、より複雑なロジックを適用できます。

現時点では両方を組み合わせていますが、これはエレガントではないようです。

これに関するガイダンスをいただければ幸いです。

4

4 に答える 4

6

私にとってOOの重要な点は、オブジェクトに自分のために何かをするように指示することです。属性を引き出して自分で決定することはありません（ヘルパークラスなどで）。

したがって、オプションb）に関するあなたの主張に同意します。追加のロジックが必要なため、コラボレーションするように追加のヘルパーオブジェクトへの参照を渡しているときに、オブジェクトに対して操作を実行しても害はありません。操作自体のときにこれを行うか、注文オブジェクトにこれらのコラボレーションエンティティを事前入力するかは、現在の状況に大きく依存します。

于 2010-10-03T10:26:07.747 に答える
2

POCOの拡張メソッドを使用して、bllメソッドをラップすることもできます。したがって、現在のbllを使い続けることができます。C＃では次のようなものです：

public static class OrderBusiness <- everything must be static, class and method
{
  public static bool CanBeCancelledOnline(this Order order) <- notice the 'this'
  {
    logic ...

そして今、あなたは注文をすることができます。CanBeCancelledOnline（）

于 2011-01-24T21:39:53.020 に答える
2

これは、アプリケーションの複雑さに依存する可能性が高く、経験に伴う判断が必要です。簡単に言うと、プロジェクトが非常に単純なものではない場合は、ロジックをドメインクラスに配置するのが最善です。

長い答え：

ロジックをサービスレイヤー内に配置すると、トランザクションスクリプトのパターンに効果的に従い、最終的には貧血のドメインモデルになります。これは有効なルートですが、通常、単純なプロジェクトや小規模なプロジェクトで最適に機能します。問題は、トランザクションスクリプトレイヤー（サービスレイヤー）が大きくなるにつれて、保守がより複雑になることです。

したがって、別の方法は、その中にロジックを含むリッチドメインモデルを作成することです。ロジックを適用するクラスと一緒に保つことは、優れたオブジェクト指向デザインの重要な部分であり、複雑なプロジェクトでは非常に重要です。通常、最初はもう少し考えて努力する必要があります。そのため、非常に単純なプロジェクトでは、トランザクションスクリプトパターンを使用することがあります。

どちらを使用するかわからない場合は、通常、ロジックをリファクタリングしてサービスレイヤーからドメインに移動するのはそれほど難しい作業ではありませんが、ジョブが大きくなりすぎないように、十分に早く呼び出しを行う必要があります。

答えの1つとは反対に、POCOクラスを使用しても、ドメインクラスにビジネスロジックを含めることができないという意味ではありません。POCOは、特定のORMに固有のメソッドやインターフェイスなど、フレームワーク固有の構造をドメインクラスに適用しないことを目的としています。ビジネスロジックを適用するためのいくつかの関数を備えたクラスは、明らかにまだPlain-Old-CLR-Objectです。

于 2013-07-24T08:40:59.013 に答える
0

よくある質問であり、部分的に主観的な質問です。

IMO、オプションAを使用する必要があります。

POCOは、まさにその「plain-old-CLR」オブジェクトである必要があります。それらにビジネスロジックを適用し始めると、それらはPOCOではなくなります。:)

確かに、ビジネスロジックをPOCOと同じアセンブリに配置できます。メソッドを直接追加せずに、ビジネスルールを容易にするヘルパークラスを作成してください。POCOに必要なのは、ドメインモデルにマッピングするプロパティだけです。

本当にあなたのビジネスルールがどれほど複雑であるかに依存します。このアプリケーションでは、ビジネスルールは非常に単純なので、オプションAを使用します。

ただし、ビジネスルールが乱雑になり始めた場合は、仕様パターンの使用を検討してください。

于 2010-10-03T10:25:50.663 に答える