ASP.NET MVC でコントローラーを整理する方法について質問があります。たとえば、連絡先用のデータベース テーブルと活動用のデータベース テーブルがあるとします。アクティビティ テーブルには ContactId への外部キーがあるため、既存の連絡先にアクティビティを追加する必要があります。
今は ASP.NET MVC です。連絡先コントローラーはアクティビティ アクションも処理する必要がありますか? または、ActivityController を作成し、これに追加、編集、削除を行う必要がありますか?
プロセスは異なる場合がありますが、ベスト プラクティスはありますか?
It is really down to how you are building your screens.
I don't know how you are building your screens but say I had an edit contact page, and part of that page displayed the list of activities and then allowed you to add/edit/delete activities. I would use Ajax to handle this and then create an Activity WebApi controller (if you are using MVC4) to handle the Ajax calls.
If you are using MVC3 then I would add the methods to the Contact controller.
EDIT:
In support of @Husein who presented his case much better than I did - it is definitely about how you want to deal with the object graph. My description above makes the assumption that you are not dealing with activities in isolation - they are dealt with only as part of a Contact object.
アクティビティと連絡先を互いに分離できるかどうか、または 1 つとして扱う必要があるかどうかは、大きく異なります。通常は、単一責任の原則に従います。基本的に、コントローラーには 1 つの義務があり、各アクションは 1 つの特定の操作を実行する必要があります。たとえば、ContactsController. コントローラには 1 つの責任があり、それは 1 つのタイプのオブジェクト (この場合は連絡先) を操作することです。この操作の一部として、それぞれに特定の CRUD 操作を実行させることで、これに対応するアクションを用意します。
一方、Activitiesfor eachがありContactます。アクティビティで何をする予定で、どのように扱うかは完全にあなた次第です。連絡先ごとにすべての登録済みアクティビティをリストする必要がありますか? はいの場合は、独自の CRUD 操作を持つ ActivitiesController として実装します。このコントローラーの一部のアクションは、コンタクト ID を受け取り、アクティビティをコンタクトなどに割り当てるのに役立ちます。
前の質問に対する答えが「いいえ」で、活動を別のプロセスとして扱う必要がない場合は、何らかの方法で連絡先に統合することを検討してください。要件が変更され、アクティビティを別のプロセスにする必要があることに気付いた場合、将来について少し考えてみてください。2 つのモデルを緊密に統合すると、それらを分離するのに苦労することになります (おそらくそれほど難しくはありませんが、首が痛くなるでしょう)。それらを今分離すると、長期的にはそれらを維持しやすくなります。これらすべてに加えて、2 つを分離すると、より軽量なコントローラーを作成するのに役立ちます。