tags:

views:

85

answers:

3

Hi

I am kinda of confused on when I should be making a new controller it seems like every time I make a button that goes somewhere I would need to make a new controller to get the right pathing names.

For instance in this scenario I have a signIn controller.

this controller would have

1. Login view
2. RestPassword view
3. CreateAccount view

So if they click login they go to some other controller(lets call it AccountController) so this will have all the account view and stuff in it.

Now how about the RestPassword view? When it rests the user password I want it to go to a page that shows them that it was a success(most sites seem to do this for example asp.net site if you enter in a email address it will go to another page and tell you that the new password has been sent).

So now what should it be another view? a controller?

If it is a view then the pathing would look like

http://www.site.com/signIn/EmailForgottenPassword

what kind of looks weird to me.

If I make a new controller then I could have

http://www.site.com/EmailForgottenPassword

What looks alot better to me but this controller would have one just one view in it.

Another example would be on this sigIn page their is a Create Account button. Now when clicked this goes to another page that has a list of different accounts.

Should this also be a new controller? When the accounts are listed on this new page they all link to a Registration Controller with many views in it.

so it would be like SignController -> RegistrationController -> RegistrationController.

this would probably get some nice links.

So like I said it seems like to get nice links that make sense you need to constantly make new controller after controller.

So I must be missing something.

+3  A: 

The truth is you never actually need more than one controller. Separate controllers are just ways of separating your concerns. In other words, OO design paradigms impel us to logically divide our code into modules, but you don't have to - everything can be in one controller.

What you do need is a separate controller action for each different type of request you want to process. That is, you need a controller method exposed to the routing table that can be called by typing in some URL and/or providing some GET or POST data. This method then decides what to show the user (the view).

Also, you can have any URL you want point to any controller or controller action you want by modifying the routing table in Globals.asax.

You probably have more specific questions about my answer - please post them and I will edit them in.

JoshJordan
A: 

If you are following SOLID principles then you should name them very specifically. If you are using ASP.NET MVC 2 then I would put major widgets into "areas" and then give controllers good names. Make your URLs happy!

Andrew Siemer
+2  A: 

In your specific case you one controller would suffice. I would name it the AccountController and add the following actions to it.

  • Login
  • Logout
  • Create
  • CreateConfirmation
  • ResetPassword
  • ResetPasswordConfirmation

then for the ones you want to have confirmation screens you can use the the Post Redirect Get (PRG) pattern.

as to the naming. In general you want to use noun for a controller and verbs for actions on those controllers. That way you get nice readable URL's that make sense. And for the noun you can pick the logical/business term (better then the technical term) that the controller deals with. So accounts, customers, products, blogpost etc...

olle