views:

96

answers:

4

I'm writing an asp.net mvc2 project with a lot of views/partialviews. Reading on good MVC practices, I've been encourage to create ViewModels. Its really nice and makes sense to do so but I'm noticing recently that I can no longer easily remember what model is for what view. I'm hoping there is a nice naming convention for ViewModels that can handle large projects.

My question is can this situation be improved?

+1  A: 

Make it simple:

ModelName = ViewName + "Model";

If you have model hierarchies, you sometimes need to pass the model from the view to partial views. In that case the above rule can be waived.

Developer Art
+2  A: 

I always keep it very simple, for instance, if you have a model named Folder:

View = "FolderView.xaml"

ViewModel = "FolderViewModel.cs"

jsmith
A: 

I've started going one step further and specifying if a ViewModel is used to generate a Form via EditorFor by ending the name with Form. Helps keep forms vs. simple display models easily identifiable.

jfar
A: 

If you are keeping your view models in the same assembly as your views, one trick I have used to help organize views with view models in addition to a simple naming scheme like {View Name}ViewModel for the view model class is to do the following:

  1. Create your view class (Shell.xaml)
  2. In the same location, add your view model class (ShellViewModel.cs)
  3. Rename the view model class file to be the same name as the view, but append .model to the file path (Shell.model.cs)
  4. Edit the project file (either manually or using the power command extensions in VS)
  5. Locate the Compile element for the view model class in the project XML document
  6. Add a child DependentUpon element whose content is the name of the view class
  7. Save changes and reload the project

This will cause the view model class to be visually grouped along side the code-behind file for the view.

alt text

Oppositional
this sounds interesting.
Am
This looks interesting but I'm not sure whether or not it would be considered good practice. I'd be interested to hear other people's thoughts on this.
Joshua Hayes
It is useful for visually organizing the view model with the view, the same way the codebehind is linked to the view. I think the best practice comes into play regarding whether you should have your view models in a separate class library from your view, which depends on your reuse and testing scenarios. On some projects, I have had the view models in another library, but in simplier projects have placed them in the same projects as the views.
Oppositional