2

私は現在、Angular 2 を使用して一連の CRUD コンポーネントを開発しています。これまでにオンラインで見つけたすべての例ではHttp、コンポーネント内にサービスが含まれています。つまり、リソースを作成するコンポーネント (これを と呼びます) には、クラスを使用してリモート サーバー上にリソースを作成するResourceCreateコードが含まれています。Http同様に、すべてのリソースを含むリストを表示するコンポーネント (これを と呼びます) には、クラスをResourceList使用してサーバーからリソースのリストを取得するコードが含まれています。Http

ResourceListこれは、たとえば、まだサーバー上に配置されていないが、クライアント上で一時的に生成されたリソースのリストをを使用してレンダリングする場合を除き、問題なく機能します。もう 1 つの例は、ResourceCreateリソース情報を入力するためだけに を使用し、サーバーではなくローカルに保存することです。上記の 2 つのケースでHttpは、コンポーネントにサービスを含めることは冗長です。

したがって、これらのコンポーネントに対する私の考えは次のとおりです。

  • 親コンポーネントを作成し、すべての CRUD サブコンポーネント (例: 、 ) をアタッチしResourceCreateますResourceList
  • を使用してデータを送信または受信する代わりにHttp、親コンポーネントにデータを渡したり、CRUD サブコンポーネントのイベントをInput()sリッスンしたりします。Output()たとえば、親コンポーネントHttpにリソース リストをフェッチするリクエストを実行させ、そのリストをResourcetListコンポーネントに渡します。もう 1 つの例は、リソースの説明とともにResourceCreateコンポーネントにイベントを発行させることです。submitこのイベントは親コンポーネントによってキャッチされ、親コンポーネントはこれをサーバーに送信します。

このアプローチを使用することで、CRUD コンポーネントはリソース ストレージについて何も知りません。したがって、リソースがローカルまたはファイル内にある場合、変更する必要があるのは親コンポーネントのみであり、CRUD コンポーネント自体ではありません。これにより、CRUD コンポーネントがより再利用しやすくなります。

このアプローチに欠点があるかどうかを理解しようとしています。インターネットで見つけた CRUD の例で、このアプローチを使用していないのはなぜHttpですか? CRUD コンポーネント内にサービスを埋め込んでいます。何か案は?

前もって感謝します。

4

1 に答える 1