2

API 呼び出しのデータをカプセル化するために、モデル クラスと連携する REST バックエンドがあります。現時点では、同じモデル クラスを使用してデータを DB にマップしています。

API ドメインから DB ドメインへのデータのコピーを節約するため、このアプローチにはいくつかの問題があります。

  • 忘れやすい API から直接 DB に設定することを許可されていないフィールドを明示的にマスクする必要があるため、セキュリティ リスクが発生します。
  • API モデル クラスは、API 経由で提供されることが想定されていない DB ドメイン固有のメンバーで「汚染」されています。
  • API モデルを (誤って) 変更せずに DB 層をリファクタリングすることは難しくなります。

一方、コピーするときは次のとおりです。

  • (大きな) リストを返す際の問題。
  • (新しい) プロパティを API ドメインから DB ドメインに、またはその逆にコピーすることを忘れがちです。

これについて何かを言うデザインルールがあるのだろうか。

4

1 に答える 1

1

できることは、ビジネス エンティティ (データベースに書き込むモデル) をデータ転送オブジェクトから分離することです (つまり、DTO パターンを使用します)。したがって、最終的には次のとおりです。

  1. 残りからのデータであるあなたのコンテナであるDTO
  2. 受信データを読み取り、データを操作してエンティティに変換するビジネス ロジック。エンティティは、DAO を介して、またはその他の方法でデータベースに書き込み/読み取りが行われます。
  3. データベース モデルを表すモデル エンティティ。

このようにして、少なくとも懸念事項 (セキュリティ、API の変更、データ転送) を分離できます。

これは、人生のすべて（ビールを除く:)）にはマイナス面があります。たとえば、重複したコードを取得します（dtoのdbエンティティからモデルを複製する必要があります）。これにより、オーバーヘッドが発生する可能性があります。

それが役立つことを願っています。使用する言語はわかりませんが、Java の例を次に示します: http://www.oracle.com/technetwork/java/transferobject-139757.html

于 2013-07-08T18:01:31.837 に答える