我正在使用 MVVM 编写我的第一个 WPF 应用程序，我对视图模型的角色以及我应该在哪里放置应用程序启动时应该运行的代码感到困惑。
我的应用程序非常简单。它列出了来自远程位置的文件，然后用户可以从中选择以复制到他们自己的计算机上。当应用程序第一次启动时，它必须从配置文件中确定当前文件的来源，从源头读取当前文件，并在主窗口中将它们列出给用户。如果找不到配置的文件源，则会提示用户选择一个源。
这个逻辑应该放在 ViewModel 中吗？如果是这样，它应该进入视图模型的构造函数吗？这似乎不对，因为我不希望 ViewModel 读取配置文件，并在实例化时提示用户。
如果这是一个 WinForms 应用程序，我会在 Form.Load 或 Form.Shown 事件中执行此操作。
通常，主要数据加载代码可以保存在单独的视图模型函数中，例如ViewModel.Initialize()......更重要的是在后台线程上，因为它在执行时不会挂起 GUI，直到那一刻你可以在 GUI 上显示一个忙碌的服务员目标。
您可以让它Command为您的轻松驱动（例如 Relay/DelegateCommand 等InitilizeCommand），并且Initialize()方法可以是命令的Execute委托。
Initialize()可以根据您的方便调用...从 ViewModel 的构造函数开始，或使用附加行为处理Window/UserControl.Load事件并调度“ViewModel.Initialize()”函数，只要该函数在不同的后台线程上，我们很好。
如果您使用 的模式和实践PRISM，像这样的数据加载可以自动适合特定模块，作为 Prism 所代表的复合 GUI 整体设计的一部分。
一个好的 MVVM 教程在这里... http://msdn.microsoft.com/en-us/library/gg405484%28v=pandp.40%29.aspx
如果您有一个简单的应用程序并且已知启动时间不长，您可以使用 unity 引导您的应用程序。
做这一切的一切都显示在一个非常好的 MVVM 视频介绍中，可以在这里找到： Jason Dollinger on MVVM
他在此视频中开发的源代码也可以使用： 模型-视图-视图模型视频的源代码
除此之外，您的引导逻辑（读取配置，...）应该清楚地由视图模型控制。您仍然可以拥有一个 ConfigSource，它可以进行读取并且可以在后台线程中运行。
实现该 Source，您可以拥有一个接口，它可以轻松地将您的 ConfigSource 与从数据库或其他地方读取数据的接口交换。并且：您可以从统一中获得这样的实例，更多地从具体实现中解耦。您可以使用构造函数注入：
即 viewmodel 被引导 => 获得一个 ConfigReader 注入 => 调用 ConfigReader（在 BackgroundThread 上） => 视图被填充
最好不要在 ctor 中执行复杂的逻辑。如前所述，最好定义Initialize()方法（如果它是IInitializable接口的成员就更好了）。
如果您的应用程序非常简单并且没有计划对其进行太多扩展，您可以组合Model和ViewModel分层并在ViewModel. 但是如果您的应用程序足够复杂，Model则应通过构造函数将类注入到ViewModel. Model类包含所有逻辑，ViewModel 使用它们来执行操作和显示数据。