2

REST WCF サービスに送信されるクライアント要求を表すクラスを使用する必要があります。

しかし、私はこのリクエストをビジネス層のメソッドにも渡したいと思っています。(現在は WCF サービスの一部です)

[DataContract] マーク クラスをビジネス層に持つのは悪い設計ですか?

4

4 に答える 4

2

これは有用な答えであることがわかりました。基本的に、属性DataContractSerializerを追加せずに POCO をシリアル化できます。[DataContract]

https://stackoverflow.com/a/14185417/1099260

于 2013-01-09T10:22:24.917 に答える
2

コメントで述べたように：

それが気に入らない場合は、そのクラスによって実装されているインターフェイスを導入し、それをビジネス レイヤーで使用します。DataContract 属性は、シリアル化エンジンの単なるマーカーであることに注意してください。

于 2013-01-09T10:46:03.593 に答える
0

他のオプションがコントラクトを別の「BL クラス」にほぼ複製することである場合は、DataContracts を特定のレイヤーに送信しないことについて気分を良くするために、DataContract を送信しないでください。

また、「リクエスト」、「コマンド」、および「データ転送オブジェクト」は、厳密には「ファサード」オブジェクト (またはパターン) ではありません。メソッドの署名を簡素化し、将来のリファクタリングを可能にするために、DAL API (階層化されたアーキテクチャを想定しています) で要求オブジェクトを使用できますよね? では、すべてのレイヤーで同じリクエスト オブジェクトを使用してみませんか?

実際の DataContract 属性に関して展開の問題がある場合 (私には思いつきません)、それは別の話です。

于 2013-01-09T10:27:04.670 に答える
0

将来、REST WCF クライアント要求サービスのさまざまなインターフェイスが必要になり、消費するクライアントを制御できない場合、BL が WCF コントラクト クラスに大きく依存していると、問題が発生する可能性があります。BL を壊さずにサービス インターフェイスを変更したり、クライアントへのインターフェイスを壊さずに BL を変更したりすることが困難になる場合があります。

上記のいずれにも当てはまらない場合は、@Rahal がコメントで言ったことを先に進めてください (私は彼を +1 しました)。

于 2013-01-09T10:40:05.543 に答える