レガシーサービスからのWCF：デザインアプローチ

Question

私はすでにレガシーサービスが働いている状況があります。このサービスには、レガシービジネスオブジェクトが配置されています。製品チームは、WCF技術を通じてサービスを公開することに決めました。ネットワーク上でDTOを送信するさまざまなアプローチは何でしょうか？

私は考えることができソリューション：。。

1）DataContracts全体のビジネス・オブジェクトを変換は、（WCF特定の名前空間で自分のレガシーシステムを汚染）

2）は、その新しいのDTO（DataContractsを）書きます既存のビジネスオブジェクトをラップします。 （これは、何らかのラッパーを書いていることを意味するので、パフォーマンス上の問題が生じる可能性があります。）3）提案できるその他の方法。

私は正しい方向に考えていますか？上記の2つより良いアプローチがありますか？

に関して、

Answer 1

あなたが正しく理解している場合は、アプリケーション内で使用する一連のビジネスオブジェクトが既にあり、これらのオブジェクトを公開するサービスを作成するためにWCFを使用する必要があります。

私は答えがだと思います。それはに依存します。

通常、ビジネスオブジェクトが成熟しており、変更する可能性が非常に低い場合は、WCFサービスを通じてそれらのオブジェクトを公開することができます。 monnbは、WCFはあなたに属性を追加することなくこれらをうまく動作させると述べています。しかし、時間の経過とともにビジネスオブジェクトを変更する可能性がある場合は、苦痛の世界に陥るでしょう...たとえば、サービスのバージョン1をリリースし、人々がそれを使い始めると、すべての人が幸せになると言うことができます。しかし、既存のビジネスエンティティにいくつかの変更を加える必要があります。これを行うと、新しいオブジェクトを使用するようにWCFサービスが更新されます。つまり、が契約を破ったことを意味します。。あなたが公開するDTOの背後にあるアイデアは、あなたのサービスと消費者の間の契約であると考えられており、これを頻繁に変えることは悪いことです。

私はあなたがきれいなアプローチをし、WCFサービス用の新しいDTOオブジェクトを作成することをお勧めします。その後、WCFの "レイヤー"でこれらを排他的に使用します。これらのオブジェクトと従来のオブジェクトとの間を必要に応じてマップするには、AutoMapperを使用します。私はWCFで出始めていたとき

は最後に、私は、これは大きな助けであることがわかった：http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight-2

Answer 2

あなたと同じように、あなたの（既存の）実体、DataContractSerializer will still serialize DTO年代に[DataContract]/[DataMember]/[EnumMember]属性のいずれかに追加しない場合、あなたの決断

1. であなたを助けるかもしれないいくつかのポイント期待、すなわち公共の特性。
2. あなたはどのようにあなたのエンティティWSDLの「見た目」や結果、特に1の周りの名前空間とラッパーとのメッセージを、より細かく制御が必要な場合：Nの関係を、あなたが財産を続ける場合は、あなたもMessageContractの代わりのDataContract
3. を見て検討すべきではAutoMapperのようなツールは、小さな実績ではあるが、内部エンティティの外部転送オブジェクトへのマッピングを非常にシンプルにします。