asp.net-mvcdesign-patternsgranularity

Which granularity of controller is appropriate in MVC style for a big web site?


We (my team and I) have a big web project that will deal with many users (at least 15,000 users!). In elaboration phase we decided to code in MVC style. We confront a tradeoff (in this project all of actions should be performed by authenticated users).

One way of designing could be: controller gets the request and according to it, creates (loads from DB) the responsible object for the request, then a reference of that object is saved to the controller and at last controller is added to the session of user. This style needs controller to be a coarse granular class with multiple behaviors among possible actions of user that have high frequency.

The other way of designing could be: controller gets a request then create the responsible object for the request but this controller is stateless and have specific behaviors according to for example one page of the web site. In this way for each page we should create a controller and if it needs information that common in some pages we must load them from DB or cache of it.

My request: I want to compare them with two aspects, memory usage and performance! And if there is any suggestion I will really happy to mention it!

For a simple example please see the below pic:

http://v1.iimmgg.com/images/is7gr/fb0f6b763eea5294815dcb2d50a12f56.png


Solution

  • My rule of thumb is to follow REST principles

    Every business entity is a resource. Resources should have controllers.

    Value objects like e-mails, money etc. are not resources.

    In few cases, controllers should be merged when simplicity over-weights complexity additional controller would add and entities are directly related.