就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用或专业知识的支持，但这个问题可能会引起辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center为指导。
9年前关闭。
我想开始收集 MVVM-light(带 RIA 服务)最佳实践。我发现有许多项目是有用的最佳实践或最佳方法，但希望听到其他使用 MVVM-light 工具包的人的意见，看看他们也发现了什么。
请发布您的最佳实践作为此问题的答案。
MVVM-Light 的基本用法
在 App.cs 文件的 Application_Startup 函数中初始化 DispatcherHelper 从 BaseClass 创建 ViewModel 始终创建一个 ViewModelLocator 类，该类包含您所有的 View 模型并链接到您的应用程序资源 使用 RelayCommands 将函数公开给您的 View 了解何时使用 DispatchHelper。 清理思路:
在适当的时候，添加到您的 ViewModel 以在 Cleanup() 上清除您的 DomainContext 的 EntitySet？ 调用您的 ViewModelLocator 的 CleanupSomeVM() 函数以在应用程序中不再需要它们时清除 View 模型。 我很想听听其他人何时/如何使用 CleanUp 功能。随着我的应用程序的增长，我确实觉得需要添加一些清理功能来更好地管理客户端内存使用情况。
对于可混合性:
将服务/查询实现抽象为接口(interface)。 为每个服务实现类创建 2 个类(1 个用于设计，1 个用于生产)在您的每个 ViewModel 中，实现其自己的服务类(使用 IsInDesignMode)以根据需要创建可混合服务实现。 使用静态变量将您的 DomainContext 保存在服务实现类中。 在 ViewModels 的构造函数中添加 DispatcherHelper.Initialize()，但仅限于在设计模式下。 Blend 在加载页面时不会加载 App，这可以解决这个问题。 对于添加的业务逻辑:
首先在 Model 中添加业务逻辑，然后在 ViewModel 中。 使用模型的部分方法为适当的更改/更新事件添加逻辑。 添加只读属性(仅限 getter)以提供模型的汇总值和计算值。 对于 View :
始终将根绑定(bind)到定位器对象。 尝试将代码隐藏逻辑仅用于布局或自定义 UI 逻辑。避免引用您的 ViewModel。 对于收藏:
将 CollectionViewSource 用于 ViewModel 中的集合，并使用 DomainContext 的 EntitySet 的来源
将所有过滤、排序和分组逻辑应用于 ViewModel 中的 CollectionViewSource。 在 ServiceCalls 之后，根据需要在 CollectionViewSource 对象上调用 .View.Refresh() 以更新 UI。 用于 ViewModel 协调( Controller 逻辑)
谨慎使用消息，过多的复杂性可能难以管理。 使用 NotificationMessage 和 PropertyChangedMessage 类来发送/接收。 对于 RIA 域服务:
在持久更改功能中实现任何日志记录，而不是更新/插入/删除逻辑。 在 Insert、Update、Delete 函数中，如果需要通过 Navigation Property 引用另一个 Entity，要么先检查 EntityStatus，要么从另一个 Context 加载该实体，以防止 EntityStatus 冲突。 对于调试/测试:
检查输出窗口是否存在绑定(bind)错误并修复它们。绑定(bind)错误会以静默方式向用户失败，但会降低应用程序性能和预期行为。 在 Silverlight 中创建单元测试以验证任何添加的模型/业务逻辑 创建单元测试项目以测试服务器端逻辑和功能 对于 Entity Framework :
保持 EntitiesContext 与域服务的 1 对 1 匹配。尝试以另一种方式拆分会导致问题。 不要使用 [Composition] 属性，除非您完全打算花费大量时间仔细构建插入、更新和删除逻辑。 使用单独的服务将自定义类型返回给您的 RIA 客户端。不要将它们添加到您的 EntityFramework 对象的 DomainService 在 PersistChangeSet 函数中执行服务器端更新/集成逻辑(例如更新其他系统)，而不是在 Insert、Update、Delete 函数中。这将防止您通过导航属性意外地拉入实体，这将使您的分离版本未更新。 创建额外的上下文以在更新/集成逻辑期间查找当前值。