views:

326

answers:

4

I've been nesting my viewdata classes inside my controllers and, as their numbers grow, I'm starting to ask myself if this is a good idea. Then again, something about polluting the /Views and /Controllers directories with these things seems off.

Is there a convention I'm missing here? Maybe a /ViewData directory? idk, what are some good locations for my viewdata classes?

A: 

I put my view data classes in a project dedicated to just that. They are DTO's, and putting them in their own project enforces that they do not depend on anything above in the architectural layers.

Using them as DTO's to deliver to views is just one way of putting them to use. I might send them over the wire some time, inside a message on a service bus or whatever.

mookid8000
+3  A: 

I don't know of a convention. I just put mine under /Model/ViewModel/BlahViewModel.cs, etc. I wouldn't put them in a separate project until there was a specific need for that. It wouldn't be difficult to move them later on if needed.

John Sheehan
A: 

I did exactly what you're suggesting, I have my strongly typed viewdata living in /ViewData. I thought about putting it in the \Model directory but I don't like my projects having too many nested directories. the \ViewData is also what Kigg does.

ajma
A: 

since you are using MVC and the folder structure should represent the namespace structure of your code I would recommend for each of your object domains you should group your controllers, models and services into seperate folders

we would use

  • DomainName

         Controllers
         Model
         Services
    
Richard
right, but where would you put the viewdata classes? Controllers and Views are dependent on them.
TheDeeno
In the model folder, as you will want to pass the model to the view from the controller. MvcContrib has some excellent extensions to allow you pass data models into the viewdata such as ViewData.Add(modelInstance) and ViewData.Get<ModelClass>()
Richard