虽然在我的应用程序中添加了额外的功能，但我已经意识到代码量很快就会成为问题（目前我的viewmodel中大约有600行代码，而且我仍然有很多补充）。View and ViewModel变得太大
我一直在寻找有关如何拆分/设计您的视图到更小的组件的文章，但我还没有找到一个令人满意的解决方案。有人建议使用子视图模型，但是会出现其他问题（视图模型之间的依赖关系）。
我曾经想过使用用户控件，但是我没有在View上使用其他视图，所以它有点挫败了用户控件的用途。
这种情况下的正确方法是什么？
感谢， 阿德里安
如果要拆分视图成组成部分，那么你需要做的视图合成。如果你正在构建一个MVVM应用程序，然后you should really be using an MVVM framework。像Caliburn.Micro这样的东西使得视图组合非常容易。
视图模型之间不一定必须有依赖关系，他们应该只知道他们需要什么来产生他们的视图。这可能是父视图模型包含的业务对象的子集。由于父视图模型将引用所有子视图模型，因此它可以在构建时将业务对象的相关部分传递给它们。
我也同意Caliburn.Micro是一个很好的解决方案，用于在较小的组件中分割您的应用程序。
在Caliburn.Micro中，视图模型之间的通信基于Event aggregator模式。
这使的ViewModels
我会同意使用微卡利之间的松耦合。
但是，要扮演魔鬼的拥护者，你可以将你的ViewModel文件分割成不同的文件（同一个类名），并在class关键字之前使用partial关键字。它通常更加整洁和一步离开（非破坏前兆）分解成不同的类别。
分裂并不理想。
它看起来好像Caliburn工具包关注事件，而我的应用程序很大程度上依赖于ICommand实现。
对我来说，第一次遇到Caliburn.Micro并不理想。 该设置似乎是为VS2010量身定做的 - 这对我来说听起来很有保证 - 因为我的确拥有VS2010专业版。但是我迷失在了Silverlight的设置中。 与像Prism这样的工具包相比，它缺乏启动的简易性。 现在需要很长时间才能切换。 我使用自己的MVVM范例，它比Caliburn更抽象，它集成了多语言支持，并且由于Binding/DataContext范例的性质，它只是面临一些可接受的问题，因为某些源过大。 对于这个问题，我接受“部分类”是一个解决方案 - 即使我知道有一个更优雅的解决方案可用。
在我的工作中，我无法改变为另一个工具包。
因此，我微微等待Microsoft允许围绕该绑定/数据上下文范式提供更多的灵活性。
这可能是Caliburn显示更多智能将视图模型分配给某个项目的情况。可以 ？ （我认为是）
另一种选择是定义一个自定义（xaml可用）对象，该对象触发一个自定义分配器，该控制权将被分配给哪个视图模型。那个怎么样 ？
我不打算写我的答案 - 这是一个更加雄辩的方式来说，比我能做的。我还必须赞同使用Caliburn.Micro的建议。我发现它有一个温和的强大的学习曲线，但后来我同时学习了WPF和MVVM。这是我从现在开始创建的任何客户端应用程序的唯一出路。 –
谢谢，我会给Caliburn.Micro一个尝试。 – Adrian