1

.NET および WCF アプリケーションで、ビジネス メッセージをサービス メッセージに変換し、サービス メッセージをビジネス メッセージに変換するために、EntityTranslator を維持する負担が増えます。実際、DB からフェッチして同じものを更新する必要があるだけなので、それらをビジネス オブジェクトとして呼び出すことはできません。デバイスからデータを読み取り、DB に保存し、DB からデータを読み取り、デバイスに保存します。

私たちのすべてのクラスは単純でプレーンな .NET クラスであり、特定のことは何もしません。

よく似たクラスです。

これが私のサービスエンティティです。

[DataContract]
public class LogInfoServiceEntity
{
   string data1;
   string name;
}

public class  LogInfo
{
   string data1;
   string name;
}

次に、トランスレータを定義して、反対側のインスタンス タイプを作成し、反対側のデータをコピーする必要があります。このようなクラスが約 25 ありますが、それらを管理するのは非常に難しいと感じています。したがって、25 人の企業からサービスへの翻訳者と、25 人のサービスからビジネスへの翻訳者がいます。

すべてのトランスレーターを使用するよりも、情報を保存して取得するための単純な POJO のようなクラスが好きです。

状況を処理する最善の方法は何ですか? または、翻訳者は状況を処理するための最良の方法ですか?

4

3 に答える 3

2

Automapperは、あなたが探しているものかもしれません。

于 2009-11-23T13:46:29.597 に答える
0

これはばかげた質問かもしれませんが、どうしてですか？

「ビジネス メッセージ」に使用するのと同じクラスを DataContract に使用しますか?

通常、データ コントラクトに影響を与えずにビジネス オブジェクトを変更できるように、コントラクトを個別に保持します。

于 2009-11-23T16:36:57.397 に答える
0

答えは「場合による」です。システムの複雑さにのみ依存します。通常、WCF サービス インターフェイスは粗粒度にする必要があり、サーバーへの追加のラウンドトリップを防ぐために、必ずしもビジネス レイヤー エンティティに 1 対 1 でマップする必要はありません。

たとえば、WCF インターフェイスの Customer エンティティは、ビジネス層の Customer エンティティに直接関連していなくても、より多くの情報を伝えることができます。ただし、85% の状況でクライアントが顧客データだけでなく、すべての注文/アクティビティまたはその他の補足情報を数分以内に必要とすることが予想されるため、この情報を追加で返します。

これは通常のトレードオフです - より多くを返すか、より少なく返すか。

あなたの特定のケースでは、コード生成に固執します。ビジネスロジックエンティティからすべての外部インターフェイスとトランスレーターを生成するツールをいつでも作成できます。

于 2009-11-23T13:46:34.010 に答える