データ転送オブジェクトを導入するか、REST
MVVMアプリケーションに取り組んでいます。 RESTインターフェースを公開しているジャージー（バックエンド）と、このインターフェースの唯一のコンシューマーであるAngularJS（フロントエンド）。アプリケーションは、以下に提示されるモデルとは異なる複雑なデータベースモデル（データモデル）を使用します。ブラウザのユーザー（ビューモデル）。
現在、次のジレンマに遭遇しました。
- モデルで複雑なビジネスロジック操作を呼び出すために必要なすべての属性を含むデータ転送オブジェクト（DTO）クラスを導入する
- dTOクラスを導入せずに既存の複雑なデータモデルを公開する
アプローチ1では、RESTインターフェースのクライアントがデータモデルを理解する必要がなく、DTOクラスで必要なすべての属性の値を提供するだけでよいので、クライアントを単純に許可します。ただし、このアプローチでは、データモデルとビューモデルの間で、バックエンドにマッピングレイヤーを導入する必要があります。
アプローチ2の結果、バックエンドのコードが少なくなりますが、既存のデータモデルへのユーザー入力のマッピングを行う必要があるため、フロントエンドのコードはおそらくより複雑になります。
REST設計の視点からのアプローチ2の方が優れているようですが、RESTでデータモデルを公開することは常に最良のソリューションですか？
dTOクラスを導入せずに既存の複雑なデータモデルを公開する
このアプローチの大きな欠点の1つは、データアクセスレイヤーとAPIを結合することです。これらのモデルがAPI以外の場所で使用されている場合、非常に速く悪化する可能性があります。私は現在、WebインターフェイスとJSON API（RESTの一種ですが、完全ではありません）が同じHibernateエンティティを使用するプロジェクトに取り組んでいます-それはfragileです、 1つの場所でのすべての変更が他の場所に影響するためです。再利用性はこのように機能しないだけだと思います。
モデルがAPIに適合しない場合、DTOが必要になる場合があります。たとえば、APIクライアントから非表示にしたいいくつかのトリッキーな検証ルールまたはいくつかのデータがある場合。あなたは注釈を付けて狂ったように行くことができますが、それでも常に機能するとは限りません。
JSON APIとウェブインターフェースの両方を備えた他のプロジェクトにも取り組んでいますが、APIは独自のデータアクセスレイヤー（ jOOQ ）を使用しています。データにアクセスする方法は2つありますが、正常に機能します。データエンティティからDTOへの「トランスフォーマー」のレイヤーを用意するよりも、APIのカスタムクエリを記述してデータをDTOに入力する方が簡単です。また、ORMよりも速くmuch動作し、 lazy fetching および「Open Session/EntityManager」に関連する問題のクラス全体を排除しますビュー」パターン。
そのため、DTOを使用することをお勧めします。また、APIに別の非ORMデータアクセスレイヤーを使用することも検討します。 ORMはWebインターフェイス（およびおそらくRPCスタイルのAPI）に適していますが、RESTで多くの問題を引き起こしているようです。これは [〜＃〜 ] cqrs [〜＃〜] 。