在 MVC 控制器中使用存储库和服务引用

Question

我在为我的 mvc 应用程序确定解决方案时遇到了一些麻烦。

背景。

我们有一个 EF 模型，通过 WCF 服务（而不是数据服务）对其执行操作。

我有一个 MVC 应用程序，它有许多存储库，这些存储库直接与服务通信并将 WCF 类型返回到调用存储库方法的控制器，该类型称为例如 WCFUserEntity（实际上并不以 WCF 为前缀）。

在控制器内部，我计划将 WCFUserEntity 自动映射到 ViewModel 实体。

这个解决方案让我烦恼的是，因为我将 WCFUserEntity 返回到控制器，所以我必须在控制器中引用 WebService 代理，这不适合我，我希望我的控制器一无所知存储库从哪里获取数据。所以我的另一个选择是在存储库内部进行自动映射并将 ViewModel 实体返回到控制器，但我找不到太多支持这个想法的东西，所以我真正想要的是验证第二个解决方案或帮助第三个。

谢谢，多姆

Answer 1

您可能需要考虑第三种选择。

ViewModelBuilder 的使用。

在您的控制器中，它们将像这样工作：

var myViewModel = myViewModelBuilder.WithX().WithY().Build();

WithX 和 WithY 是在内部向视图模型添加内容的方法（在构建器中，例如 WithCountriesList() 如果您想添加显示视图中国家/地区的下拉列表），并且 Build 方法将在添加所有内容后返回内部视图模型使用 WithXXX 方法的位。之所以如此，是因为大多数时候您可能想要添加下拉列表和不属于原始模型（在本例中为您的 userEntity）的内容。

这样，您的控制器就不知道如何构建视图模型，您的存储库也与视图模型无关。所有工作都在 Builder 中完成。缺点是，您需要为每个 ViewModel 创建一个 ViewModelBuilder。

我希望这有帮助。

Answer 2

我如何处理这个问题可能需要一些架构更改，但我建议您使用 WCF API 返回 ViewModel 而不是实体。

首先，请考虑带宽问题（如果您在 Azure 或云中托管 WCF，这将是一个问题）。如果您的 ViewModel 仅使用一些特定属性，为什么要浪费带宽返回其他数据呢？在高流量情况下，这可能会导致流量浪费，最终可能会造成金钱损失。例如，如果您的视图仅显示用户及其问题，则没有理由通过网络发送他的电子邮件、答案、点数等。

另一个需要考虑的问题是急切加载。通过让 WCF 服务返回一个 ViewModel，您就知道您在一次访问 WCF 服务的过程中就拥有了视图所需的所有数据（即使它与相关实体相关）。您不需要获取 WCFUserEntity，然后向 WCF 请求与该特定用户相关的 WCFDocumentEntities。

最后，如果您的 WCF API 是围绕 ViewModel 构建的，那么您对所涉及的业务流程会有更清晰的了解。您知道该特定请求（以及系统中的视图）将为您提供该特定信息，并且如果您需要不同视图的不同信息，那么您就知道这是一个完全不同的业务请求，具有不同的业务需求。以堆栈溢出为例，很容易看出该业务流程正在向当前用户询问相关问题，而该业务流程正在向当前用户询问相关答案。

在数据检索 WCF API 中使用 ViewModel 意味着您的前端层不一定知道数据来自哪里，它只知道它调用了业务流程并获取了所需的数据。据了解，数据层直接连接数据库而不是WCF。

编辑：
重新阅读后，这实际上看起来像是你的第三个选择。网上的大多数研究都没有谈论这个选项，我不知道为什么，但是在经历了一些类似的挫折之后（加上本文中列出的其他内容），这就是我处理业务层的方式。它更有意义，而且实际上（恕我直言）更容易管理。