2

私はこのパターンを何度も見て、意見を求めたかった:

オプション 1: ワイヤー オブジェクトとビジネス オブジェクトの構成について:

ワイヤ オブジェクト- シリアル化され、マシン間 (クライアント/サーバーなど) 間でやり取りされるデータ。これは POCO オブジェクトです。

例えば：

public class Order
{
    public int Price;
    public int Amount;
}

ビジネス オブジェクト- 通常、一部またはすべてのプロパティをオン ワイヤー オブジェクトとして持つ別のクラスですが、いくつかの計算フィールドも持ちます。これは通常、「ワイヤー上」のオブジェクトの上にコンポジションを使用します。

public class OrderBusinessObject  
{  
     private Order _order;

     public OrderBusinessObject(Order o)
     {
          _order = o;
     }

     public int Price {return _order.Price;}  
     public int Amount{return _order.Amount;}  
     public int Total{return _order.Price * _order.Amount;}            
}

オプション 2: 変換によるワイヤー オブジェクトとビジネス オブジェクト:

これはワイヤー オブジェクトで例 1 と同じですが、ビジネス オブジェクトでは合成を使用する代わりに翻訳を使用します。

public class OrderTranslator
{
    public OrderBusinessObject Translate(Order o)
    {
         OrderBusinessObject bo = new OrderBusinessObject();
         bo.Amount = o.Amount;
         bo.Price = o.Price;
         return bo;
    }
}

public class OrderBusinessObject  
{    
     private int _price;
     private int _amount;

     public int Price {return _price;}  
     public int Amount{return _amount;}  
     public int Total{return _price * _amount;}            
}

オプション 3: ビジネス オブジェクトをまったく持たず、すべての計算を別の電卓クラスで実行します。注: 消費者は、通信中のオブジェクトと電卓を取得します

public class Consumer
{
     public void ShowTotal(Order o)
     {
         Calculator calc = new Calculator();
         double total = calc.ShowTotal(o);
      }
}

ここにベスト プラクティスやパターンがあるのか​​、それとも単にユーザーの好みの問題なのかについて、人々の意見を聞きたかったのです。

4

1 に答える 1

2

エンタープライズ レベルのシステムでは、オプション 2 を使用することをお勧めします。この方法は、SOA 環境でのコントラクト優先の開発に役立ち、ドメイン オブジェクトをワイヤ表現から独立したままにすることができます。これにより、時間の経過に伴う契約の変更が容易になり、ドメインとデータの連絡先が互いに独立して変更できるようになります。変換コードは少し面倒かもしれませんが、Automapper のようなツールを使用して高速化することができます。

とはいえ、すべてのアプリでこのレベルの柔軟性は必要ないかもしれません。

私にとって、オプション 3 はオブジェクト指向およびドメイン駆動の原則に反する傾向があります。これは、動作を外部化し、貧血ドメイン モデルにつながるためです。オプション 1 は、ドメイン モデルがデータ コントラクトに依存するため、ドメイン駆動設計にも少し反します。ドメイン中心のモデルでは、これらのドメイン オブジェクトは独立している必要があります。

于 2009-10-27T13:58:39.847 に答える