問題タブ [data-transfer-objects]

Web サービスと DTO を使用して顧客情報を取得する C# Windows アプリケーションを作成しようとしています。

DTO (データ転送オブジェクト) を使用する提供された Web サービスを使用する必要があります。

SOAP UI では、リクエスト XML は次のようになります

DTOリターンは

Visual Studio で webreference を追加した後、webservice のインスタンス化を呼び出し、次のようにメンバー ID を渡すことができます。

問題は、DTO から返されたデータをどのように取得するかということです。これをフォームの適切なテキスト フィールドに書き込むことができます。

Visual Studio を使用する場合、getCustomerInfo.Address1 のようなものが表示されると予想されますが、データが DTO にあるため、このメソッドを使用してリターンを確認することはできません。getCustomerResponse DTO をインスタンス化すると、getCustomerResponse.Address1 が表示されますが、入力パラメーターを受け入れないため、値 inCustomerNumber を渡すことができません。

Dataflow = customerNumber で getCustomer を呼び出すと、getCustomerResponse DTO のすべての値が返されます。

私のサービスコードは次のとおりです

作成した DTO について

使用しなければならない WSDL

私が取り組んでいるプロジェクトで CQRS を使用しようとしていますが、現在、CQRS のクエリ側を実装する最良の方法に苦労しています。私のやや限定的な理解に基づいて、データベースにクエリを実行し、アプリケーションの UI レイヤーで使用されるクエリ結果を含む DTO を返すシン データ レイヤー (シン リード レイヤーと呼ばれることもあります) があります。

これは私が開発しているJava EEアプリケーションであるため、シンデータレイヤーはJPAを使用してデータベースにクエリを実行し、これを使用しEntityManager.createNamedQueryて結果を含むエンティティを返し、それをDTOにマッピングします。

アプリケーションのクエリ側が「読み取り専用」である必要がある場合、DTO には getter が含まれますが、各プロパティの setter は含まれず、作成時にプロパティを設定するために使用されるコンストラクターは含まれません。

単純なクエリの場合、コンストラクターを使用してエンティティの値を DTO に手動でマップできますが、これはより複雑なクエリでは実用的ではありません。特に、対応するエンティティにマップする必要がある「1 対多」の関係がエンティティに含まれている場合はそうです。 DTO。Dozer や ModelMapper などのマッピング フレームワークの使用を検討しましたが、それらはすべて DTO のセッターに依存しているようで、コンストラクターを使用していないようです。

次のコードは、状況を説明するために作成した 2 つのエンティティと 2 つの DTO の非常に単純化されたビューを表しています。

私の質問は次のとおりです。

1. CQRS を使用する場合、DTO にはゲッターとコンストラクターのみが必要ですか、それともセッターも使用できますか?

2. DTO が理想的にはゲッターとコンストラクターのみを持つ必要がある場合、マッピング フレームワークは、エンティティが "1 対多" の関係を含む複雑な結果セットを返す DTO を設定するための最良の方法ですか?

3. セッターではなくコンストラクターを使用できるマッピング フレームワークはありますか?

何時間もの試行錯誤の後、誰かが私の問題を解決するのを手伝ってくれるかどうかここで尋ねたい.

シナリオ：

• JAX-WS 実装として Apache CXF を使用する Java EE サーバー (JBoss 7.2)。
• ServiceA (サービス エンドポイント) と ServiceB (サービス A とサービス エンドポイントを拡張)
• 3 つの持続性プロジェクト: Common、PersistenceA は Common に依存し、PersistenceB は PersistenceA に依存します。
• すべての永続化クラスのスーパークラスであるクラスがありUUIDIdentifiedます (JPA を提供します@ID)。それはプロジェクト共通にあります

ServiceA クラス内にはメソッドがあります。public List<DTO> getData(UUIDIdentified value);

サーバーは、すべて UUIDIdentified のサブタイプであるいくつかのオブジェクトを読み取ります。目標は、オブジェクトを DTO にパックすることです。

DTO は次のようになります。

SOAP 応答を調べると、<uuididentified>タグにデータがないことがわかります。私のJAXBの理解はそれほどよくありませんが、UUIDIdentifiedの「実際の」インスタンスとそのタイプはJAXBContextには不明です。

クラスに追加すること@XmlSeeAlso({TypeA.class,TypeB.class})でこれを解決できました（私はそう思います）。UUIDIdentifiedしかし、そうすると、Project Common は Projects PersistenceA/B に依存することになるので、それはできません。

どうすればこれを解決できますか。UUIDIdentifiedを追加するときにClassA/BをJAXBContextに追加する必要があることをJAXB(おそらくxml構成ファイル)にどのように言えますか?

SEIでjaxb.in​​dexファイル、ObjectFactory、@XmlSeeAlsoなどを試しましたが、それが正しい方法かどうかはわかりません。

非常によく似た DTO があります。

これらは、テスト リソースを識別する 1 つのプロパティのみが異なります。

代わりに EditAddTestDTO を作成して、

次に、明らかに TestId がない Create-Scenario では機能しないため、RequireAttribute を配置することはできません。

その問題をどのように解決しますか？

既に持っているように 2 つの DTO を作成しますか、それとも AddEditBaseDTO ですか?

これはかなり主観的な質問かもしれませんが、もう少し意見を知りたいです。Spring MVC を使用して Rest API サービスを構築し、DTO-Domain-Entity パターンを実装しました。Builder パターンを DTO に実装することについてどう思うか知りたいです。

定義によると：

Builder 設計パターンの意図は、複雑なオブジェクトの構築をその表現から分離することです。そうすることで、同じ構築プロセスで異なる表現を作成できます。

私の DTO ケースのほとんど (すべてとは言いません) では、このケースのように、構築するより複雑なオブジェクトはありません。そして、正直なところ、DTO について話している場合、複雑なオブジェクトを構築する例は思い浮かびません。

不変オブジェクトを使いやすくし、コードを明確にするのに役立つパターンの 1 つに Builder パターンがあります。

Builder パターンは、オブジェクトの不変性を提供します。次に、DTOはサービス応答自体であり、これは応答であるため変更すべきではないと考えることができます（少なくともそれが私が考えている方法です）

それで、あなたはどう思いますか？このパターンを DTO に使用する必要がありますか (このケース、およびおそらくそれらのほとんどが複合オブジェクトの原則を満たしていないという事実を考えると)。