2

ORM フレームワークをサポートせずに、ドメイン オブジェクト/エンティティを永続レイヤーと組み合わせるクリーンな方法は何ですか?

ドメインクラス/エンティティzcl_documentとzcl_document_request(1:n) があります。ドメインクラスには、コアドメインロジックのみを含め、インフラストラクチャ、「ヘルパー」、永続性/読み込みメカニズムを含めないようにしたいと考えています。

ABAPにいるので、「クリーン」を定義structures zs_documentし、パブリック読み取り専用属性zs_docreqとして公開される各エンティティに対して定義しました（結局、ABAPにいます）。dataこのようにして、エンティティに多数のゲッターを必要とせず、コア ドメイン ロジックへのメソッドを最小限に抑えます。

薄い永続レイヤーを取得するために、各データベース テーブル (オプションのテキスト テーブルなどを含む) に対して -interfaces which を定義しましDAOたread。それらの戻り値の型は、エンティティ オブジェクト自体ではなく、常にまたは構造のテーブルです。したがって、テスト可能/交換可能な薄い永続層があります。この永続層は、大量のデータを処理するレポートでも使用できるようになりました。これは、オブジェクト インスタンスやオブジェクトのグラフを作成する必要がなく、(できればクリーンな) 構造で作業することに頼ることができるためです。savefind_by_xstructure

エンティティをインスタンス化するために、通常、各エンティティには public-static create(ファクトリ) メソッドがあり、「クリーンな」構造を取り、そのインスタンスを検証して生成します。create依存オブジェクトも作成する必要があるため、他のオブジェクトへの基本的な関連付けを持つエンティティは、より困難です。それらのエンティティは独自のものを取得しますzcl_document_request_manager（名前を付けます）。createManager は、関連するすべてのオブジェクトを含む方法(ファクトリ) とsaveエンティティを知っています。したがってfriend、エンティティの 1 つでもあります。

ファクトリは、エンティティ自体をインフラストラクチャ/永続性のものからクリーンに保つためにDAOを知っている唯一の場所です。ロードは熱心に行われます。エンティティにインフラストラクチャ管理コードが多すぎることなく、透過的な遅延ロードを作成する方法がわかりません。

それを使用すると、次のようになります。

create object lo_docreq_mng exporting dao, dao, dao, dao,...

lt_docreq = docreq_dao->find_by_x( ... ) // table of structure

foreach lt_docreq as ls_docreq // structure
  lo_docreq = lo_docreq_mng=>create( ls_docreq ) // factory => instance

  lo_doc = lo_docreq->get_document( ) // was created with document-instance

  lo_docreq->do_something_mutating( ).      
  lo_docreq_mng->save( lo_docreq) // save including dependent objects

これは実現可能ですか、それとも臭いがありますか？コメントをいただければ幸いです。

4

2 に答える 2

2

私はあなたのアプローチが好きです。私はいくつかのことを変更します：

1) ドメイン オブジェクトのユーザーを構築コードからクリーンに保つために、構造ではなくエンティティのリストを返す docreq-class を提供できます。

lt_doc = doc_qry->find_by_x( ... ) // table of entities
foreach lt_doc as lo_doc 
  lo_doc->do_something_mutating( ).      
  lo_doc_mng->save( lo_doc ) // save including dependent objects

この使用法はエラーが発生しにくく、コード内のビジネス ロジックを明確にします。また、エンティティが頻繁に使用されることを願っているので、他の開発者の使用を簡素化します。

2) save-Method を削除することもできます。save を明示的に呼び出す必要があるのはなぜですか? 私の経験では、何かを保存するか破棄するかの決定は、実行中のトランザクション (最上位レポートまたは実行中の UI) のコントローラーに委ねられます。しかし、ある種のビジネスやサービスのメソッド/機能に配置するべきではありません。

3) 私は静的メソッドには行きません。そもそも実装は簡単ですが、後で変更すると地獄になる可能性があります

ORM の使用に関する議論について: テスト容易性が低下するため、永続性とドメイン ロジックを混同するつもりはありません。永続層としてのみ ABAP-ORM を使用しても、大きなメリットはありません。クラスでデータをラップし、単純な abap 構造のように使用するのはなぜですか (ほとんどの場合)。一方で、適切な DQL が欠けています。

于 2013-08-04T09:30:36.497 に答える