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 ac开发者_开发百科cording 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.

• In first style, controller should be a coarse granular object because of decreasing creation and garbage collection, so it creates only one time after user is authenticated and won’t be garbage until session expiration. Life cycle of objects that exist in session is until the session is expired so I think it may be causes memory shortage!
• In second style for every transition of user to other page one controller should be created and extracts information from DB, may be causes performance problem!

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

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.

Actually dividing the site in many controllers won't make a difference from DB accesss point of view, since the object is maintained throughout the session. Splitting the site in many controllers doesn't mean you're splitting the session.

Most of the times your data access layer dictates the performance of the system with little impact of size of controller in mvc application. from design point of view, i would suggest you to keep logically related actions in one controller so you can have many small controllers. for performance point of view you should focus on your db access and find the optimization where it belongs to.