ViewModel中的ObjectContext（EF + MVVM）

我正在编写我的第一个使用EntityFramework进行数据访问的MVVM应用程序。应用程序严重依赖于底层数据库，并且在很多情况下必须将新数据添加到数据库。ViewModel中的ObjectContext（EF + MVVM）

但是，我不确定在ViewModel中调用ObjectContext是否是个好主意。例如

public class SomeViewModel : ViewModelBase 
{ 
    public IEnumerable<User> AllUsers { get; private set; } 

    private void SomeMethod() 
    { 
     var __entities = new DatabaseEntities(); 
     AllUsers = __entities.Users.Where(...).ToList(); 
    }

}

我看到了这样的解决方案，但也有一些问题，与它一起到来。例如ObjectContext实际存在多长时间，或者应该选择单个全局可访问的ObjectContext。

或者应该像那些不是虚拟机一部分的调用？目前我也可以想象为每个数据库表实现像StaticHelpers，并使用像GetAllUsers（）这样的方法。

在Josh Smith的关于MVVM的示例应用程序中，他使用在每个VM的构造函数中注入的Repository。

public AllCustomersViewModel(CustomerRepository customerRepository)

尽管事实上，这已经是一个常见的问题，我发现这个问题是如何处理的小应用程序（最佳实践），没有令人满意的答案？

来源

2013-03-26 Hartmut Weinthaler

我认为直接从您的视图模型的方法调用ObjectContect意味着，如果你没有一个很好的GetAllUsers（），可以通过不同的视图模型（如有必要）访问方法。如果你没有这样的要求，那么我认为它是相当好的。你可以在一个using中包装你的DatabaseEntities实例。我认为您当前工作流程面临的问题是管理UI更新。首先，您正在使用IEnumerable而不是ObservableCollection ，其次，您直接使用EF用户类，而不是将其包装在实现INPC的VM中。 – failedprogramming 2013-03-27 00:16:35

在MSDN上的DbContext类的描写的特征它规定"Represents a combination of the Unit-Of-Work and Repository patterns"，因此它可以为您的存储库层作用，虽然它不就得了，它的目的是要用于“工作单元”，它没有按不适合整个应用程序的全球。除了保留所有内容之外，还可能导致缓存数据和其他不良事物（内存使用等）的问题。

希望这会有所帮助。

来源

2013-03-26 19:44:06

ViewModel中的ObjectContext（EF + MVVM）

回答

相关问题