MVVM - Solution/Project organization

[techgnome]

I realize this is something of a personal preference kind of thing... but at the same time it is something of a concern.

We're getting ready to start moving towards a MVVM (modified) paradigm here, and so I've been reading a lot of material on the pattern. I think I'm now at the point where I've got a decent handle on how it works.

I know that part of the point is to reduce the coupling and dependency of the layers. That is the View should only know and care about the ViewModel. And the ViewModel only cares about the Model.

To that end, I'm noticing that every example, tutorial, sample out there (that I've seen) dumps everything into the same project. They then organize it into Views, ViewModel, Model, Command, Services, etc folders. To me this just seems silly. To me, there should be some break up. I should be able to have a project that has a dozen Views in it, with references to (let's say for example) 4 VMProjects that have been previously built. Then my Views could be Silverlight, WPF, or what ever else I decide.

Am I crazy for thinking this? How do others out there organize their M-V-XX patterned applications? Is it normal to dump everything into a single application? Or it is common to break it up? And if you do break things up in to different assemblies, what kind of structure have you used? What things have been grouped together?

We're looking for a high amount of re-usability where we can, and one of the ideas is that we should be able to slap on different Views onto the same ViewModel. It's supposed to be one of the hallmarks of Presentation Models, and yet it seems to be overlooked a lot.

I realize that they are patterns, guidelines in essence, I get the theoreticals... but sometimes putting those thoreticals is where things break down. Having everything tossed into the app like that seems to go against the pattern, while at the same time enforcing it.

-tg

[DeanMc]

Here's something that will really bake your noodle, what is to say I can't have 10 projects which are all combined into one View.

Your on the right track though. One of the AHA moments with MV-X is realising that any of the 3 parts doesn't have to be a part per se, it just has to encompass the concept.

[jmcilhinney]

What you're describing is pretty much the same as an ASP.NET MVC project. The layers are all in the same project. It's important to remember that these patterns are as much about maintainability as they are about re-usability.

Breaking the layers out into separate projects makes each one re-usable, but if you never re-use them then you've added (a small amount of) complexity for no gain. By creating separate layers within the one project you do make that one project more maintainable, because it's far easier to see all the effects of any particular change.

If you do happen to need to re-use one of the layers later, breaking it out into its own project is simple because of the logical separation you already have. Creating separate projects for the layers is certainly not a bad thing, but it's certainly not essential to benefit from such patterns.