请将您的最佳做法作为此问题的答案.
解决方法
>在App.cs文件的Application_Startup函数中初始化dispatcherHelper
>从BaseClass创建viewmodels
>始终创建viewmodelLocator类,其中包含所有视图模型,并在应用程序资源中链接
>使用RelayCommands将函数公开给您的视图
>了解何时使用dispatchHelper.
清理想法：
>在适当的时候,添加到您的viewmodel以清除您的DomainContext的清理EntitySet()？
>调用viewmodelLocator的CleanupSomeVM()函数,以便在应用程序中不再需要它们时清除视图模型.
我很乐意听到他人关于何时/如何使用CleanUp功能.随着我的应用程序的发展,我觉得需要添加一些清理功能来更好地管理客户端内存使用.
对于混合性：
>摘要接口的服务/查询实现.
>为每个服务实施类创建2个类(1个用于Design,1个用于Production)
>在每个viewmodel中,实现自己的服务类(使用IsInDesignMode)根据需要创建Blendable Service实现.
>使用静态变量将DomainContext保存在服务引用类中.
>在viewmodel的构造函数中添加dispatcherHelper.Initialize(),但仅在设计模式下. Blend在加载页面时不会加载应用程序,这样可以实现.
增加业务逻辑：
>首先在模型中添加业务逻辑,然后在viewmodel中添加.
>使用模型的部分方法为适当的更改/更新事件添加逻辑.
>添加只读属性(仅限getter)以提供模型中的摘要和计算值.
对于意见：
>总是将根绑定到定位符对象.
>尝试仅将代码隐藏逻辑保留到布局或自定义UI逻辑.避免引用您的viewmodel.
收藏品：
>为viewmodels中的集合使用CollectionViewSource,其中包含DomainContext的EntitySet的源
>将所有过滤,排序和分组逻辑应用于viewmodel中的CollectionViewSource.
>在ServiceCalls之后,根据需要调用CollectionViewSource对象上的.View.Refresh()来更新UI.
对于viewmodel协调(Controller Logic)
>谨慎使用消息,复杂度过高可能难以管理.
>使用NotificationMessage和PropertyChangedMessage类发送/接收.
对于RIA domainservices：
>在持久性更改功能中实现任何日志记录,而不是更新/插入/删除逻辑.
>在插入,更新,删除功能期间,如果需要通过导航属性引用另一个实体,请先检查EntityStatus,或从另一个上下文加载实体,以防止EntityStatus冲突.
调试/测试：
>检查输出窗口的绑定错误并修复它们.绑定错误对用户默认失败,但会降低应用程序性能和预期行为.
>在Silverlight中创建单元测试以验证任何添加的模型/业务逻辑
>创建单元测试项目来测试服务器端逻辑和功能
对于实体框架：
>将EntitiesContext的1对1匹配保留到域服务.试图分开另一种方式会导致问题.>不要使用[Composition]属性,除非您完全打算花费大量的时间仔细构建您的插入,更新和删除逻辑.>使用单独的服务将自定义类型提供给您的RIA客户端.不要将它们添加到您的EntityFramework对象的DomainService中>在PersistChangeset函数中执行服务器端更新/集成逻辑(例如更新其他系统),而不是插入,删除功能.这将阻止您通过导航属性意外拉入实体,这将使您的分离版本不被更新.>创建一个附加上下文,以便在更新/集成逻辑期间查找当前值.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。