views:

74

answers:

4

ASP.NET MVC is heavily convention-based, "convention over configuration" as they say. So, this means there's a lot of significance to what name things are given and where in the project structure they are created.

As a newcomer to ASP.NET MVC, I appreciate the power and simplicity of this approach, but I do find it a bit confusing to keep track of what conventions are in play. For example, when using UpdateModel controller method, that relies on HTML form fields having the same names as the properties of the model class. That's the obvious thing to do and most of the time it's probably what most people would do instinctively, but I can see that it would get really confusing if one were to rename something in one place and forget to rename it in the other. The linkage is somewhat 'brittle'.

So, I thought it would be useful to have a list of all the ASP.NET MVC conventions here in one place, as short statements of best practice. things like:

"HTML Form fields should have the same name as Model Properties".

Anyone have anything like that? Will you help me create a list here?

A: 

Controllers should always end with the Controller sufix.

Dejan
A: 

Controller and action names specified in routes should have corresponding classes and action methods named exactly this way (plus "-Controller" suffix for controllers). You can override this behavior using [ControllerName] and [ActionName] attributes.

Developer Art
Not sure I understand yoru first point...?
Tim Long
The first point is not a convention but just a specifics about how Html helpers are implemented. Thought it might be useful.
Developer Art
+1  A: 

Note that convention over configuration is not required, but is how things work out-of-the-box. If you find a convention confusing or not helpful you can change it (eg. how controllers are picked, how views are located, etc.), or do configuration.

Max Toro
Good point! I've seen some examples of that, but as a learner I want to fully understand the out-of-box conventions before I go overriding them. I need to get into Microsoft's mindset.
Tim Long
+1  A: 

Use the virtual path from your deployment server and enter it in the project configuration in Visual Studio. This way the visual studio development server will use the same path structure as the deployment server. This will save you countless hours of work when deploying.

John