MVVM与Entity Framework项目结构

Question

我目前正在学习WPF中的MVVM。我正在创建一个应用程序，其中使用Code First方法结合Entity Framework。我的项目应该有什么适当的结构？

MVVM具有以下结构：

Views 
ViewModels
Model 

我的当前计划是将我的POCO放到Model文件夹中。我应该把继承自DbContext类的类放在哪里？

- randacun

Answer 1

MVVM没有规定服务基础设施。虽然你的POCO domain应该保留在“Model”目录中，但DbContext不应该被MVVM实现所知道。

换句话说，不应该有一个继承自DbContext的类。

通常我通过ViewModelProvider构造提供这种类型的功能，将“实际”模型抽象出来，使其与ViewModel实现分离。这有助于更容易地进行Mocking等操作。所有具体的viewModel实现都应通过该抽象“提供”。

- bic

---

我仍然不清楚应该把我的DbContext类放在哪里。我知道DbContext与MVVM本身是分开的。我应该创建一个基础设施或DAL项目（MyProject.Infrastructure或MyProject.DAL），并将DbContext及其配置放在那里吗？谢谢。 - randacun

好的，首先我会创建一个“服务”层，您可以从中查询您的模型。然后提供一个实现，将您的模型绑定到应用程序级别的ViewModels（“ViewModelProvider”）。换句话说，您的实际DbContext访问器应该隐藏在ViewModelProvider抽象后面。这样清楚了吗？在评论中很难具体说明 :-) - bic

谢谢，这些都是有用的技巧。但是你应该把你的DbContext类放在哪里呢？它必须要有一个位置，否则实体框架将无法正常工作。 - randacun

嗯，我想我现在知道你的问题所在了。MVVM是WPF的UI“可测试”框架。好的，现在，你的DbContext不属于这个框架，那么你应该把它放在哪里呢？答案是放在WPF之外的“服务”层中。你的DbContext应该完全隐藏在MVVM之外。因此，由于MVVM没有定义服务层，你需要自己实现它。这将包括访问数据并将模型对象转换为UI使用的ViewModel对象。当你需要构建你的ViewModels/UI时，你调用这个“服务”。 - bic

说实话，这个问题也让我感到困惑。主要是因为我在WPF方面的经验不足。非常棒的答案！重要的是要将MVVM视为一个演示系统。如何在这个“演示系统”中获取内容应该由外部处理。 - Abhinav

@bic 服务层是一组具有与实体框架数据库上下文进行交互的方法的类吗？还有什么其他内容涉及到服务层。谢谢。 - Joe Slater

Answer 2

模型 (Models)、视图 (Views) 和视图模型 (ViewModels) 均是应用程序的不同层。它们实际的位置并不重要，只要它们之间的交互不违反 MVVM 模式即可。

话虽如此，我通常遵循 ASP.NET MVC 和 T4Scaffolding NuGet 包所设置的模式。安装该包后，您可以执行以下命令。

Scaffold Repository -ModelType Person

这将基于Person模型类为您搭建两个新类。

• Models\MyApplicationContext.cs
• Models\PersonRepository.cs

首先是一个标准的DbContext类，就像您所期望的那样。并不打算让您的视图或视图模型直接与此类交互。仓储类提供了对上下文的抽象；这是您应该在层之间传递的类。仓储还比DbContaxt更容易模拟，并且可以轻松地使用完全不同的技术（如WCF数据服务）来实现。

希望这个答案至少给您一个好的起点。

- bricelam

---

我需要知道 DbContext 类应该放在哪里，而不是它是否有助于 MVVM 模式。我是否应该像您在示例中提供的那样将其包含在模型文件夹中？ - randacun

@randacun，这是我的起点。随着应用程序的发展，您可能会找到更好的位置（例如像bic建议的服务层）。 - bricelam

服务层和仓储层之间有什么区别？ - Joe Slater

@AnkurSharma，你可能会在服务层中使用一个仓储。（更多细节请参见链接。） - bricelam