1

コントローラ/サービス/DAO アーキテクチャ上で Java で開発された従来の注文管理アプリケーションがあります。データ オブジェクトは、データベース内のデータを表す POJO です。基本的に、データベース内の 1 つのテーブルをマップする 1 つのクラスがありますが、ORM やエンティティ メカニズムは使用しません。これらのデータ オブジェクトはすべてのレイヤー間で渡され、Web GUI を介して注文を作成/変更/取得します。このアプリケーションには、外部システムが SOAP を介してこれらの注文を管理できるようにする WebService レイヤーもあります。WebService レイヤーは、サービス レイヤーに依存して、WebService と GUI の間で同じロジックが使用されるようにします。

WebServices API を可能な限り安定させようとしていますが、現在データ オブジェクトを WebService メソッドのパラメーターとして使用しているため、その API は頻繁に変更される可能性があります (少なくとも、データベース内のフィールドを変更するたびに)。 . さらに、データベース構造の複雑さを WebService クライアントに隠したいと考えています。たとえば、データベースには、クライアントから隠したい複数のフィールドが含まれています。

具体的な質問:

  • クライアント API を介してデータベース構造とフィールドを非表示にするために一般的に使用される設計パターンはどのようなものですか?

  • パブリック メソッドのパラメーターと内部データ オブジェクトの間の "マッピング" を処理するための適切な方法はありますか?

  • データ転送オブジェクトは私の質問に対する答えですか?

4

3 に答える 3

2

プロセス境界を越えてデータ オブジェクトを渡すべきではありません。アプリケーションが脆弱になり、スキーマを変更するたびに多くの再作業が必要になります。私の提案はこれです：

-データ アクセス レイヤーは、データベース オブジェクトの作成、読み取り、更新、および削除を処理する必要があります。DAL のユーザーは、データベースを使用するためにデータベースがどのように機能するかを知っている必要があります。

ex (疑似コード):

Person = {
PERSON_ID:'1234567jksjgkhsduw0909wueioksgt',
FIRST_NAME:'CHRIS',
LAST_NAME:'MCCALL',
TITLE:'',
GENDER:'M',
LAST_NAME_SUFFIX:null,
Addresses = [{ADDRESS_ID:1234,...}]
}

など - サービス レイヤーはデータベース スキーマを変換して複雑さを隠し、このデータを使用してアプリを作成しようとする開発者にとって何が本当に役立つかについて意見を投げかけます

元：

Person = {
name:'Chris McCall',
primary_address:'123 Main St',
secondary_address:null
}

ID を含めるかどうかを決定できます。フィールド名の大文字と小文字を変更したり、アプリ開発者にとってより意味があり、データベース スキーマよりも安定した形式にデータを射影する場合があります。たぶん、あなたはたくさんのものを残しているので、ネットワークを通過するデータは少なくなります. そのようなもの。

DBA は、正常に動作し、正規化によってストレージを最大化するデータベースを作成する任務を負っています。これは、呼び出しの結果が保持されることを期待しないサービス層とは異なる目標です。

アーキテクチャが異なれば、View Model の名前も異なります (これを私はこれと呼んでいます)。DTO は別の名前です。

于 2012-12-13T16:34:43.213 に答える
0

WebServices API をできる限り安定させようとしていますが、データ オブジェクトは WebService メソッドのパラメーターとして使用されるため、API は頻繁に変更される可能性があります。

あなたはすでに間違った方向に進んでいます。Web サービスは、プラットフォームにとらわれない方法での相互運用性と統合に関するものです。
Web サービスに渡されるすべてのオブジェクトは「データ ホルダー」である必要があり、ビジネス ロジックとは関係ありません。これらの「データホルダー」をアプリケーションに必要な実際のクラスにマップするコンバーターが必要です

于 2012-12-13T16:44:55.157 に答える
-2

私自身の質問に答える：

構造化データをパブリックAPIに公開するという問題に明らかに直面しています。これらのデータは、内部で管理されるドメインモデル（データオブジェクト）から取得されますが、ドメインモデルはパブリックAPIを介して直接公開してはなりません（MUSTNOT）。

代わりに、データ転送オブジェクト（DTO）またはビューモデルと呼ばれることが多い別のクラスのセットを作成して維持し、パブリックAPIの入力/出力パラメーターとして使用する必要があります。このようなDTOを使用すると、パブリックAPIを変更せずにドメインモデルを変更でき、パブリックAPIを非常に適切に制御された方法で変更できます。

一部のマッピング（バインディングとも呼ばれます）は、ドメインモデルとDTOの間のアプリケーションで維持する必要があります。多くの場合、両方向に。Javaマッパー/バインダーライブラリの素晴らしいリストはここにあります

于 2012-12-14T15:24:21.473 に答える