私は最初の SPA を構築しており、エンティティごとに DTO を構築するところまで行っていますが、簡単な方法を見つけたところ、更新/追加/を最適化するために変更を最小限のパッケージにシリアル化する処理を行っているようです。等
私が DTO を作成した理由は、データを「平坦化」してネットワークに送信するデータ量を制限するためですが、Breeze が処理してくれる場合、このオーバーヘッドが必要になるかどうか疑問に思っています。
私は最初の SPA を構築しており、エンティティごとに DTO を構築するところまで行っていますが、簡単な方法を見つけたところ、更新/追加/を最適化するために変更を最小限のパッケージにシリアル化する処理を行っているようです。等
私が DTO を作成した理由は、データを「平坦化」してネットワークに送信するデータ量を制限するためですが、Breeze が処理してくれる場合、このオーバーヘッドが必要になるかどうか疑問に思っています。
DTOには理由があります。「データの平坦化」はその 1 つではありません。「送信するデータ量を制限する」こともありません。
Breeze は、オブジェクト グラフをうまく処理します。顧客に 100 件の注文を送るとします。各注文 DTO で顧客名を繰り返す必要はありません。Breeze を使用すると、Customer の注文を照会し (「expand」を使用)、Customer の 1 つのコピーとそれに付随する注文を取得します。
var query = new Breeze.EntityQuery.from('Customers') .where('Id', 'eq', 42) .expand('注文');
一方、顧客名のリストのみが必要な場合は、「射影」を使用します。
var query = new Breeze.EntityQuery.from('Customers') // すべての顧客 .select('ID, 会社名'); // 匿名の 2 プロパティ オブジェクトに射影する
ときどきサーバー側の DTO を使用して、クライアントからは簡単に作成できないものを構築します (たとえば、Customer-and-total-current-year-order-dollars)。
要点は、ニーズに合わせて DTO、プロジェクション、およびエンティティ クエリを組み合わせることができるということです。どちらか一方に行く必要はありません (私の意見では)。