CODEWITHSUNDEEP
asp.net-mvc
x1886x
x1886x

Reputation: 1227

How should MVC Controllers be organised?

  1. Is there a general rule of thumb to how controllers should be organised?

  2. Should Controllers only be created if they are linked to a domain model?

For instance if I have a 'Product' model, I would have a ProductController, which would have actions such as 'GetProductDetails' etc...

But what about things that don't have an actual model, such as searching for products, and returning multiple products on a page?

Since the Product model is the underlying model for all these interactions, should this functionality be included into the ProductController and have actions for searching and displaying multiple products, or should another be created for Search?

Upvotes: 0

Views: 79

Answers (2)

invernomuto
invernomuto

Reputation: 10211

You should manage every action which involve same resource with same controller, and you should implement that solution in accord with Richardson Maturity Model

A model (developed by Leonard Richardson) that breaks down the principal elements of a REST approach into three steps. These introduce resources, http verbs, and hypermedia controls.

so your API will be something like this:

/api/products GET Gets full list of all categories

/api/products/123 GET Gets the details for a single category

/api/products PUT Replaces the entire list of categories with the one given

/api/products/123 PUT Update the specified category

/api/products POST Creates a new category

/api/products DELETE Deletes all categories

/api/products/123 DELETE Deletes the specified category

Upvotes: 0

Hargrovm
Hargrovm

Reputation: 1063

If you follow the pattern used by the scaffolding used in visual studio then yes you end up with one controller per entity so a product controller would have a actions that returned a list, a single product and an action for posting update to. In addition you might have additional search actions and any other product related actions. Which is just state and reinforce infer-on's answer.

However the reason why you would do this is that it means your code is easier to maintain - if you're looking for code to do with products you have one controller class to look in. You're also adhering to the principle of separation of concerns each controller is only concerned with one type of entity.

Further to this if your app grows much larger and you use an IoC / dependency injection pattern then you only need to inject one repository or business service per controller that is a search controller that offers methods to search for products and customers would need services or repositories for customer and products but a request might only be a customer search so the creation of the products repository was pointless hence you get inefficient and overly complex code. There are patterns to solve this issue but they involve even more code so to avoid this and to keep it simple stick to one root entity one controller.

Upvotes: 1

Related Questions