Solid guidelines for establishing controller/view relationships in MVC 3
I've recently started working on a project based on Microsoft .NET MVC 3. Progress has been good so far, but I keep having a nagging feeling that might design is not 100% as it should be, mostly regarding the relationship between controllers and views.
We know that a controller can handle one or more views. I've been establishing those relationships from a business standpoint; for example, all the views that relate to accounts are handled by an Account 开发者_StackOverflow社区controller.
Is this the right approach? Because having a 1:1 relationship between views and controllers seems pretty wasteful to me.
Any pointers, tips and links will be greatly appreciated.
Thanks!
Generally it is a good idea to lump like functionality together-- I find that a good rule is to have your controllers model the problem domain, as opposed to a rule like one view per controller. In that sense it is perfectly reasonable to have one controller exposing multiple views.
the way i look at it is...
this server side controller... what is its purpose?
- it might need to allow users to log in
- it might need to show users a list of cars
- it might need to let users download a file
- it might need to allow users to edit details of a row in the database
then divide your controller requirements into post/get
and then ask... do i need a view (a screen) to complete the requirement? if you do then add a view for the method of the controller.
精彩评论