Html.RenderAction()ビューのレンダリングに使用するのが適切な場合とそうでない場合については、少しわかりません。私の理解では、これはASP.NET MVCの「公式」コンポーネントではないため、使用するのは悪い習慣であり、本来の目的は、特定のコントローラーコンテキストに存在しない再利用可能なウィジェットでした。
重要なのは、RenderActionは、現在ビューをレンダリングしているコントローラーとは異なるコントローラーの下に存在するコンポーネントが必要な場合に非常に便利です。これは、現在のビューで使用できないデータに依存するコンポーネントをレンダリングするための非常に整然とした自己完結型の方法だと思います。私が使用していた場合のように、私のビューはモデルを提供する必要はありませんRenderPartial()
これは悪い習慣ですか？もっと良い方法はありますか？
それがあなたの問題を解決する場合にはそれはOKです。
これは、現在のビューで使用できないデータに依存するコンポーネントをレンダリングするための非常に整然とした自己完結型の方法だと思います。RenderPartial（）を使用している場合のように、ビューでモデルを指定する必要はありません。
実はそうです。たとえば、ウィジェットとして機能する小さなビューを作成し、必要な場所に挿入することができます。これらのウィジェットからのユーザー入力の処理はさらに複雑になる可能性がありますが、それは別の問題です。
私が考えることができるもう1つの正当なシナリオは、HTMLメールテンプレートを使用することです。これは、レンダリングされた出力をブラウザに直接返す必要がなく、電子メールの本文に挿入する必要がある場合の1つです。
私はHtml.RenderAction()あなたが与える理由で使用します。そのため、ユーザー情報を表示する必要があるすべてのビューに同じデータを何度も提供する必要はありません（たとえば）。ビューがコントローラーについて認識しているため、MVCパターンに違反していると主張できます。しかし、このシナリオの利点はそれを上回り、アプリケーションはよりドライになると思います。
さまざまな場所で再利用する必要があるすべてのもの（たとえば、マスターページのすべてのページに表示するユーザーデータ）に使用するだけで、その情報を各ビューに明示的に送信したくありません。誤解しない限り、asp.net mvc 2にも含まれていると思うので、フレームワークの一部になりました。
親ビューのモデルの結果に基づいたシナリオでHtml.RenderActionを使用する大きな理由を見つけました。たとえば、親ビューのモデルには、テーブルに表示する必要のあるListプロパティがありました。ただし、親ビューで条件付きIF / ELSEを防ぐために、Html.RenderAction（）を呼び出します。アクションはリストを取得し、カウントをチェックします。カウントがゼロの場合、「結果なし」ビューを返します。それ以外の場合は、リスト内のアイテムを独自のモデルの形式で処理するビューを返します。これは、ロジックがビューに挿入されないようにすることで、よりクリーンになります。アプリの他の領域で「結果なし」ビューを再利用することもできます。