tags:

views:

167

answers:

5

I am about to create a ViewModel to pass some data to a View. So if the application structure is convention based. Where are the ViewModel definitions to be kept. I could create a new directory called ViewModels, but what is the RIGHT way.

+3  A: 

I don't think there's a widely accepted convention for this.

I have 'ViewModels' folder too.

Arnis L.
Yup, there's no overwhelming convention. I suspect most people have a "ViewModels" folder, or plonk their view models in the generated "Models" folder (especially if their actual model is coming from another assembly).
Iain Galloway
Odd, I don't even put my ViewModels in a ViewModel folder in my MVC apps... I call them Controllers, usually.
Will
+2  A: 

I keep my view models in the Models folder because my data models reside in a separate assembly.

Josh Bush
Even better. I dislike this style of naming too (i.e. adding Service postfix to service class name if it's in .Services namespace already).
Arnis L.
Ok... services seems to be a bad example because services are usually named with verb. But the idea remains.
Arnis L.
+1  A: 

We've reluctantly settled on a models folder as well even though our views and controllers are in separate assemblies. We painted ourselves into the corner since we also use some of our WCF client-side DTOs directly in the view but those WCF client-side DTOs are generated in our controllers assembly. I blogged about our dilemma in some greater detail.

Trinition
+1  A: 

I keep all VM in a separate assembly (dll), so you can run tests easily against them - even outside ASP.NET scope...

Dani
There can't be that much to test with view models?
tpower
A: 

You shouldn't have a ViewModel in an ASP.NET MVC application. You're getting mixed up with WPF's MVVM pattern, which is a different beast (same genus, tho).

The convention in ASP.NET MVC is to have your controllers under the Controllers directory at the root of your solution. Check out the ASP.NET MVC website template.

Now, if you're talking about the Models, the same applies as above (Models folder, check the template). These are conventions and not hard rules, so depending on how anal you are you can put them pretty much wherever it makes sense.

Will
I think you missed the point Will, see http://girldeveloper.com/waxing-dev/asp-net-mvc-translated-for-the-web-forms-programmer-5-in-a-series-what-the-frig-is-a-view-model/ to understand the process I am talking about.
Peter Marshall
Actually, you missed mine. Its Model-View-Controller in ASP.NET MVC. Its Model-View-ViewModel in WPF. Same basic pattern, but two entirely different implementations. Controllers in MVC sit ontop of views and models, whereas the ViewModel sits between views and models. The differences are dictated by the different application architectures. So, whenever you're talking about ASP.NET MVC, talk in terms of Models and Views and Controllers. If you say ViewModel you're confusing two entirely different things.
Will
http://blogs.msdn.com/dphill/archive/2009/01/31/the-viewmodel-pattern.aspx
Will
The Model-View-ViewModel pattern used for Silverlight/WPF is not the same thing as the MVC pattern in ASP.NET MVC, you're right so far. The ViewModel mentioned here is not the same thing as in MVVM though, there it's also acting as the controller (as used in MVC). In ASP.NET MVC, the ViewModel can be used for separating the actual model objects from the views, ideally as pure passive data carriers.
Freed
MVVM is MVC for WPF. Same pattern, adjusted for the architecture of WPF applications. If user input could be routed directly to VM methods there wouldn't be a need for MVVM (possibly other considerations as well). Also, you're dangerously close to taking fire in the "anemic models" war. I'd be careful how much you talk about stripping logic from models. I heard a guy did that in another question and he got his question closed and migrated to guantanamo.stackoverflow.com. Also also, you made the same mistake as Peter -- there is no VM in MVC; its the Controller. Nyah.
Will