1

C＃クライアントとJavaサーバーがあります。ワイヤーを行き来するデータオブジェクトがあります。それらをFooData.csと呼びましょう。ここでは、すべてが単なるgetとset（ロジックなし）です。

FooData data = new FooData();
data.Price = 10;
data.Quantity = 20;

アプリケーションで使用したい他の派生フィールドがありますが、ネットワーク上で送信する必要がないため、クラスがあります

FooWrapper.cs。

データオブジェクトをラッパーに挿入します

FooWrapper wrapper = new FooWrapper(Foodata);
wrapper.Price = 10;
wrapper.Quantity = 20;
double total  = wrapper.GetTotal();

ラッパーにはデータオブジェクトと同じプロパティがたくさんある（そして委任するだけです）か、ラッパーにもいくつかの計算されたプロパティがあります。ラッパーが持つ唯一の状態はデータオブジェクトです（他のメンバー変数はありません）

このモデルを使用するのか、コンバーターを使用するのかについて議論がありました。コンバーターの方法は、FooWrapperを使用する代わりに、FooBusinessObjectを使用し、「on thewire」オブジェクトを挿入する代わりに、onthewireオブジェクトからビジネスオブジェクトにすべてのデータを渡すconvertメソッドを呼び出すことです。

FooData data = new FooData();
FooBusinessObject busObj = new FooBusinessObject();
busObj.Price = data.Price;
busObj.Quant= data.Quantity;
double total  = busObj.GetTotal();

何が優れているかについての考え（ラッパー対ビジネスオブジェクト/コンバーター）

4

4 に答える 4

1

質問の書き方、私が見ることができる唯一の本当の違いは、コンストラクターを介してfooDataインスタンスを渡すか、それを構築する別のメソッドを呼び出すかですが、最初のメソッドでは、Wrapperオブジェクトが元のオブジェクトですが、2番目のアプローチでは、この接続を回避しているように見えます。

根本的な問題は、元のオブジェクトへの参照を保持したい場合に本当にあると思います。これは、元のオブジェクトに、アプリケーションに公開しないが更新を実行するために必要である可能性がある状態が含まれている場合に関連する場合があります。

そうでない場合は、ワイヤレベルのオブジェクトをビジネスロジックから隠そうとします。ラッピングの目的の一部は、ワイヤーレベルのものの詳細からコードを保護することです。スタックの上位にあるものを浸透させるほど、意図しない場所で使用される可能性が高くなり、意図しない結合が増加します。 。

于 2009-02-08T13:04:23.517 に答える
1

(編集) どのバージョンの C# を使用していますか? C# 3.0 では、ビジネス ロジック アセンブリの拡張メソッドに「ロジック」ビット (計算など) を配置できますが、DTO 経由でそれらを表示できます。

(データ層)

public class Foo {
    public int Bar {get;set;}
}

（ビジネス層）

static class FooExt {
    public static int Blop(this Foo foo) {return 2 * foo.bar;}
}

(UIレイヤー)

Foo foo = ...
int blop = foo.Blop();

データの転送に使用しているモデルは何ですか? ウェブサービス？xml? データ契約？バイナリ？ほとんどの場合、追加のコードなしで追加のプロパティを無視できます (つまり、ラッパー/ファサード オブジェクトは必要ありません)。

XmlSerializer:

[Serializable]
public class MyData {
    public int Foo {get;set;} // is sent
    [XmlIgnore]
    public int Bar {get {...} set {...}} // is ignored
}

DataContractSerializer:

[DataContract]
class MyData {
    [DataMember]
    public int Foo {get;set;} // is sent
    public int Bar {get {...} set {...}} // is ignored
}

バイナリについて話している場合は、「プロトコル バッファ」などの移植可能な Java/C# 対応モデルがあります。Jon Skeet には、公式の Java バージョンのC# ポートがあります (両側で非常によく似たコードを使用できます)。より C# 慣用的なバージョン ( protobuf-net ):

ProtoSerializer:

[ProtoContract]
class MyData {
    [ProtoMember(1)]
    public int Foo {get;set;} // is sent
    public int Bar {get {...} set {...}} // is ignored
}
于 2009-02-08T13:26:00.493 に答える
0

私はワイヤ オブジェクトを使用して他のオブジェクトを構築し、ラップしない傾向があります。「データがどのように転送されるか」と「オブジェクトがメモリにどのように格納されるか」は 2 つの異なる問題であり、それらを混在させないことは一般的には良い考えです。ある時点で、既存のワイヤ オブジェクトと互換性のない別の「ワイヤ」テクノロジを使用する可能性があります。その場合、コア ビジネス ロジックよりもコンバータ クラスを変更したいと思います。

これにより、中核となるビジネス機能に影響を与えることなく、ワイヤ オブジェクトを柔軟に変更して、より多く/より少なく/異なるデータを含めることができます。私の本では、万能の勝利です。

于 2009-08-06T05:27:26.663 に答える
0

行き来するオブジェクトの観点から考えるのではなく、一方が他方に通知する必要があるビジネス イベントと、それぞれを説明するために必要な最小限のデータ量の代わりに考えることができますか?

于 2009-02-08T15:00:28.587 に答える