Any reason not to keep ViewModels in a separate, xaml-not-allowed assembly?

Just wondering if I am shooting myself in the foot if I put all my ViewModels into a separate assembly from the xaml of my silverlight application? Do I lose any blendability?

It just seems more natural to me to have the ViewModels, which are (or should be) completely UI independent, in a separate assembly from the Xaml/views.

Do I lose anything in the area of blendability?

Im thinking it pretty much forces ease of unit testing, or am I missing something?

I found one post on this that agrees with my sentiment, but MVVMLights default project creation seems to put them together, s开发者_JAVA百科o Im wondering if I am missing the point...

It's not necessary, but it can be nice to do if you are striving for architectural purity. While VM library reuse is not common (as LBugnion said), it is quite common to retool your UI (or create a new one), in which case it can be very convenient to have a UI only assembly.
This also makes things simple if you are doing what i've heard talked about but never seen praticed in real life: having an independent UX designer work on the UI while the rest of the developers do the real code behind the scenes.

Following this practice will become more tiresome though if you have a larger project and are using something like Prism to manage modules - not only will you have several modules, each of those modules will have separate assemblies for UI and viewmodels/models, so you end up with many assemblies which can be difficult to manage or navigate.

So long as the libraries are included in the solution, you can reference the ViewModels and not lose Blendability".

Normally (as we use PRISM) we collect all business-domain specific information into one module, so it will include Views, ViewMOdels, Controllers etc, but having a separate ViewModel library (or libraries) is OK and you are using MVVM Light.

We do this often for larger applications. For small ones, it is typically not really needed. Separating the assemblies like this does not have a real technical advantage (you rarely reuse a VM library) so it's really about organization of work and structure. In terms of Blendability, you don't lose anything. Also, if you work with services, you'll need to have the interface definition in the VM library (or in a 3rd project).

Note that sometimes you get confusing build error messages. If the VM library doesn't compile, you may see errors about non-existing objects in the XAML, which are simply caused by the fact that the library is not built yet. Don't get confused.

Cheers Laurent