Josh
Josh

Reputation: 815

When should an item have its own controller in MVC architecture?

I'm currently build an MVC application (ASP.NET particularly, but I suppose this is a broader question as well). I've seen this asked on SO in a couple of different contexts, but I wasn't able to get clarity for my own situation from those discussions. I have controllers such as:

I also have some items that are less clearly managed with controllers, and this is where my question comes in. After signup, our customers are required to fill out many different aspects of their "Profile", such as business information, payment cards, bank accounts, manager contacts (name/phone).

Currently we've created a "ProfileController", with post/get functions such as:

    [HttpGet]
    public ActionResult Business()

    [HttpPost]
    public ActionResult Business(...)

It's also going to have something similar for their bank account information, payment cards, managers, etc.

This feels wrong. Should this all be moved into AccountController? Are these items throw-ins that don't really deserve their own controller, or should each of these components have their own controller?

Upvotes: 4

Views: 2045

Answers (1)

VJAI
VJAI

Reputation: 32758

Developing an MVC application is much kind of developing a REST application, you can apply the principles of REST on developing an MVC application. First you have to think in terms of resources. As per REST, a resource is an entity that can be accessed through an URL.

If you feel each model that you are talking above is a resource and the user can access it through a separate URL then you can go ahead and create a separate controller for each else the single AccountController is fine.

If you sketch the resources and URLS then you can easily identify how many controllers you have to create in your application.

Upvotes: 4

Related Questions