1

データとメソッドを含むエンティティ (クラス) があります (Person と呼びましょう)。このオブジェクトのデータを使用する必要がある他のクラスがあります (それらの 1 つを Accountant と呼びましょう) が、そのメソッドで機能を使用する必要はありません。

Person オブジェクト全体を Accountant に送信するか、データを保持してそれを Accountant obj に送信するためだけに新しい PersonData オブジェクトを作成する方がよいでしょうか?

これを把握する必要があるケースが 1 つありますが、それを全体で利用できるように、最も一般的な回答を知りたいです。

4

5 に答える 5

4

一般に、シリアル化された形式でデータを消費する必要がある場合、たとえば Web サービスやスマート クライアントなどで DTO を渡します。ドメイン内で Person オブジェクトを使用しているだけで、適切にカプセル化されているのであれば、なぜ DTO を作成する努力をしなければならないのでしょうか?

于 2009-12-22T19:50:58.953 に答える
2

他の人が述べたように、転送が含まれていない場合を除いて、DTOを使用しても意味がありません... :)

私が提案する解決策は、渡されたオブジェクトをAccountantインターフェイスに抽象化し、それIAccounteePerson実装することです...私はC#に精通していません(あなたのプロフィールから、あなたが選んだ言語だと推測しました:))が、これはおそらくあなたを正しい方向に向けるはずです:

class Accountant {
    //....
    public void performAction(IAccountee target) 
    {

    }
}
interface IAccountee
{
    string Name
    {
        get;
    }
    int Salary
    {
        get;
        set;
    }
}

class Person : IAccountee
{
    //implementation here, as well as some stuff specific to Person
}

基本的に、それは SOLID のDです:) ... 柔軟でクリーンであり、不必要な情報を共有することも避けます ...PersonAccountant

私が理解している限り、C# インターフェイスは (ほとんどの言語と同様に) 変数を必要とすることができないため、アクセサーを作成する必要があります (デフォルトのプレーン アクセサーを生成する言語/IDE 機能がない限り) まだ作成していない場合...単純な変数を使用するよりも少し時間がかかり、単純なフィールドアクセスよりも多くのパフォーマンスが必要ですが、OTOH、少なくともパフォーマンスが得られない場合は、良い習慣だと思います...間違いなくそうだと思います追加の DTO クラスを作成してデータを前後に (または少なくとも一方向に) コピーするよりもエレガントです ...

それが役立つことを願っています...;)

于 2009-12-22T20:33:23.330 に答える
1

OOP では、person クラス内で定義されているように「get」メソッドを使用する必要があると言えます。会計士はオブジェクト全体を必要とせず、選択的なデータだけを必要とするため、私はオブジェクト全体を送信しません。不必要な大規模な冗長性を作成しているため、後者ではないと思います。

しかし、このようなOOPは非常に理想化されているため、別の方法で行う方がよいかもしれません...

于 2009-12-22T19:52:57.410 に答える
1

私は通常、データのクロスレイヤー転送に DTO を使用します。そうでない場合、それを作成する説得力のある理由がわかりません。

于 2009-12-22T19:55:15.737 に答える
0

これは信頼境界の問題だと思います。ビジネス アプリケーションでは、通常、信頼境界によってレイヤー アーキテクチャが決定されます。「Accountant」が Person の信頼境界の外にある場合、何らかのモデル変換が必要です。アーキテクチャと要件によって、どのような種類の変換が行われるかが決まります。

于 2009-12-22T20:10:13.787 に答える