0

特定のプロパティのみの書き込みと更新を要求しているが、すべてのプロパティの読み取りを要求している要件を取得しています。これを処理する最良の方法は何ですか? これはクレイジーに聞こえるかもしれませんが、要件は、SOAP 経由で書き込み/更新が行われ、REST 経由で読み取りが行われることです。SOAP API は最初のデータ ロードに使用され、Web インターフェースのエンド ユーザーがより詳細な変更を行い、別のエンド ユーザー セットが REST API に対してプログラムして Web ページにデータを表示するという考えです。ベスト/グッドプラクティスに関するフィードバックやコメントをいただければ幸いです。これは、私が行う必要があると考えていることです（注、省略された例）：

namespace DTOs.Create
{
    public class Project
    {
        public string Name { get ; set; }
    }
}


namespace DTOs.Read
{
    public class Project
    {
        public string Name { get ; set; }
        public string Description { get ; set; }
        public DateTime DueDate { get ; set; }
        public int Priority { get ; set; }
    }
}
4

2 に答える 2

0

私は DTO を 1 つだけ持つ傾向があります。DTO の目的はデータを運ぶことです。動作セマンティクスを付加するべきではありません。サービス操作がこれを提供します。

プロジェクト情報 (DTO) をさまざまなコンテキスト (さまざまな操作) で使用できる必要があります。

プロジェクトを定義するものの定義がSOAPとRESTの部分で異なる場合、他の問題がある場合、プロジェクトの定義はドメイン内で一貫性を保つ必要があります。

2 つのインターフェイスは時間の経過とともに分岐する可能性がありますが、分岐はデータが何であるかではなく、データがどのように使用されるかにあります。

1 つのインターフェイスが本当にそのような異なる情報を必要とする場合は、新しいドメイン コンセプトを作成してください。それはもはや元のプロジェクト コンセプトではありません。

于 2012-05-15T10:49:56.853 に答える
0

実装のライフサイクルを通して考えてください。残りのインターフェイスと SOAP インターフェイスが時間の経過とともに分岐する可能性がある場合は、必ず 2 つの異なる DTO クラスを使用してください。

特定の状況では、2 つのインターフェイスを緩めるために 2 つの DTO を保持します。私はプロジェクトで、「インターフェースのこの軽量部分を変更することはできませんか? それはただの 1 つの文字列です!」というようなことを何度も耳にしました。そして、インターフェイスがアプリケーションの他の部分と密接に結合されているため、達成するのに多大な労力がかかります。

しかし、それはアプリケーションの範囲に大きく依存します

于 2012-05-13T11:14:34.147 に答える