角度2のCRUDコンポーネントとは別のアプローチ

Question

私は現在、角度2のCRUDコンポーネントを開発中です。これまでオンラインで見つかったすべての例では、コンポーネント内にHttpサービスがあります。つまり、リソースを作成するコンポーネント（ResourceCreateと呼ぶ）には、Httpクラスを使用してリモートサーバー上のリソースを作成するコードが含まれています。同様に、すべてのリソース（ResourceListと呼ぶ）を含むリストを表示しているコンポーネントには、Httpクラスを使用してサーバーからリソースのリストをフェッチするコードが含まれています。 を使用して、サーバーにはまだ存在しないがクライアント上で一時的に生成されたリソースの一覧をレンダリングしない限り、これはうまくいきます。もう1つの例はリソース情報を入力するだけですが、サーバー上ではなくローカルに保存するためにResourceCreateを使用することです。上記の2つのケースでは、コンポーネント内にHttpサービスを持つことは冗長です。

したがって、これらのコンポーネントのための私の考えは以下の通りです：

• 親コンポーネントを作成し、すべてのCRUDのサブコンポーネント（例えば、ResourceCreate、ResourceList）を添付してください。
• Httpを使用してデータを送信または受信する代わりに、親コンポーネントにデータをInput()sに渡すか、CRUDサブコンポーネントのイベントを受信します（Output()）。たとえば、親コンポーネントにHttp要求を実行してリソースリストを取得し、そのリストをResourcetListコンポーネントに渡すようにします。もう1つの例は、ResourceCreateコンポーネントがリソース記述とともにsubmitイベントを放出することです。このイベントは親コンポーネントによってキャッチされ、親コンポーネントはこれをサーバーに送信します。

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

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

ありがとうございます。

Answer 1

angular.io

によると、Aコンポーネントは、我々はこれが理想的に、我々はそれらに関連した見解を持っているコンポーネントを作成する必要があることを意味し

ビューを呼び出すことができ、画面の不動産のパッチを制御します。アプローチの欠点は、作成したコンポーネントが完全なコンポーネントライフサイクルを経ることです。これは、ビューが関連付けられていないため、ケースのオーバーヘッドになります。

また、ビューに要素を入れずにアーキテクチャを作成することはできません。どのコンポーネントの通信部分もビューから独立している必要があります。

より良い方法は、ストレージメカニズム（http /ローカル）をラップし、CRUDコンポーネントに注入するサービスを作成することです。これにより、CRUDコンポーネントをデータストレージから分離することができます。