フロントエンドでドメインモデルを変更するのはアンチパターンですか？
クイズアプリケーションを作成しています。Angular 2 UIとREST apiを統合します。
クイズドメインモデルは、次の（簡略化された）階層で構成されています。
-クイズ-カテゴリー-質問-選択
親は子を知らないが、子は親を知っている。たとえば、選択肢には質問への参照がありますが、質問には選択への参照がありません。このアプローチを選択したのは、クイズデータをより柔軟でモジュール化したアプローチでフェッチできるようにするためです。また、循環参照を回避します。
ただし、ビューはドメインオブジェクト構造のより深い階層で自然にレイヤーごとに構築されるため、フロントエンドでは逆リンクを使用するのは直感に反しています。最初に質問のビューをレンダリングし、その後に選択肢のサブビューをレンダリングすることは理にかなっています。それは、現在のドメインモデルでは不可能に思われます。Choiceから始める必要があります。
私の質問は、フロントエンドでドメインモデルを変換するのが一般的または承認されている場合、すべてのデータを収集し、選択肢の参照を質問に追加して、モデルをトップダウンアプローチに対応できるようにすることですか？そしてもちろん、POST時にREST api。
これは悪い設計を示していますか、それともドメインモデルの変更が承認されていますか？
ドメインモデルをWeb APIレイヤーのリソースとして使用することは非常に一般的ですが、通常は適切なことではありません。ドメイン層には、Web APIを含むクライアントがあります。 Web APIには、UIを含むクライアントがあります。ドメインクライアントのニーズと要望は、Web APIクライアントのニーズと要望と同じではありません。
クライアント用のWeb APIを記述します。クライアントが質問リソースから関連する選択リソースへのリンクを持つことが最善である場合は、そのリンクを含めます。クライアントが選択肢を組み込んでほしい場合は、それをオプションにします。 Webレイヤーから複数の高額な呼び出しを行う必要があるためにドメインレイヤーがハンマーで打たれることを意味する場合は、ドメインレイヤーを修正して、Webレイヤーに必要なものを提供します。
APIがこのようにモジュール化されるように設計されている場合、フロントエンドモデルを「反転」するのが一般的です。これは技術スタックに関係ありませんが。 asp.net mvc、php、angularのいずれの場合でも、Webサイトはトップダウンで取得するため、明示的かどうかにかかわらず反転を実行します。
この反転がAngularで非常によく見える理由は、Angularがネストされたコンポーネントフレームワークであるためです。また、入れ子になったコンポーネントでは、深いオブジェクト階層をそのまま維持する必要があります（したがって、明示的な反転）。これはasp.net mvcとは対照的です。この場合、フレームワークは深くネストされたコンポーネントに適していません。そのため、開発者はオブジェクト階層のレベルを個別のコントローラーを持つ個別のページに分割するか、階層を単一のモデルにフラット化してAPI呼び出しを調整する単一のコントローラーを備えた単一のビューに表示されます。したがって、「反転」効果は明確ではありません。
だからはい、あなたは反転する必要があり、それは受け入れられます。
これとは逆に、トップダウンアプローチでドメインを構築し、トップダウンアグリゲートアプローチでAPIを構築することで、クライアントでの逆転を防ぎ、非常にパワフル/角度のある便利な方法です。次に、データアクセスレイヤーで反転を行う必要があります。