MVC3 - 在哪个模块中引用单独的服务项目？答案

【问题标题】：MVC3 - reference to a separate service project in which module?MVC3 - 在哪个模块中引用单独的服务项目？
【发布时间】：2012-12-19 17:38:44
【问题描述】：

初始情况：

我想构建一个具有分层架构的 MVC3 应用程序。这些层将是持久性层（存储库模式）、服务层和视图层。我还想将实体映射到持久层，并将这些 DTO 传递给视图。

在视图中，我想通过使用 MVC3 weapp 来应用 MVC 模式。现在我的问题是，我应该在哪个模块、控制器或模型中访问（引用）服务层。我总是在控制器中看到对服务层的引用，如下所示：

public class CustomerController
{
 public ViewResult Details( int id )
    {
       CustomerDTO customerDto = MyService.GetCustomerById();
       return View( customerDto );
    }
}

我不应该访问模型模块中的服务层吗？如果我在控制器中访问我的服务层，我根本不需要模型模块...？

【问题讨论】：

如果已经有了服务层，还需要模型层吗？如果服务以您需要的确切格式返回它，则无需添加额外代码。在这种情况下，您的服务层就是您的模型。
好的，在我看来我不需要模型层，因为我有一个单独的服务层。但相反，我会为每个视图创建 ViewModel。

标签： c# asp.net-mvc-3 model-view-controller design-patterns

【解决方案1】：

我的工作始终基于服务层的任何实际工作都在控制器中完成。

如果我在控制器中访问我的服务层，我根本不需要模型模块...？

不正确 - 您的服务类型极不可能具有，甚至应该具有正确的形状和元数据（例如[Display] 或 [DataType] 归属）或使它们与 MVC 视图一起正常工作。您应该为所有提供给视图的对象使用模型类型，即使它们是您的服务类型的一对一克隆 - 因为这样您的视图和控制器所需的数据与您的服务之间就有了分离类型。

如果您尝试将视图直接绑定到您的服务类型，那么您正在创建以下两种情况之一：

使得更改视图和控制器代码变得更加困难，因为来回发送的数据必须符合服务类型
使更改服务类型变得更加困难，因为这样做意味着更改每个视图

ViewModel（或Model，取决于您的观点）是适合查看（显示在网页上）和绑定（从网页接收）之间的适配器 - 就是这样这两件事通常会偏离业务逻辑级别使用的实际服务类型。他们确实应该，因为他们的目标是解决不同的问题。

【讨论】：

非常感谢，这听起来合乎逻辑。我也应该将来自服务层（主要是 DTO）的数据映射到控制器中的模型对象（ViewModel），对吗？对于这个提议，你会推荐实现一种映射器类吗？
或者您可以使用构造函数来执行此操作 - 复制物理数据或简单地包装实例。一旦你有了分离，你如何映射它们就取决于你了。模型类是愚蠢的，因为它们不一定与服务层对话，但是当涉及到它们与服务的关系 type 我经常在它们无所不知的基础上工作，所以没有其他代码需要担心。

【解决方案2】：

取决于您是否要从控制器中隐藏 MyService。

在您的示例中它是可见的。如果你在 Model 上有一个同名的方法，然后委托给 MyService，那就不会了。

隐藏它的好处是您可以将 MyService 替换为 YourService 而不会影响 View 和 Controller 层。

至于没有模型。那么你在哪里定义你的 DTO 呢？基本上 MyService 将是您的模型。

您还假设模型到控制器查看的 DTO 始终相同，即使添加至少一个其他层也是如此。

如果我是你，我会考虑这个假设......

【讨论】：

我在一个单独的项目中定义我的 DTO，就像一个普通项目一样。但我认为现在很清楚，我不能使用我的 DTO 从服务层到控制器，再到视图。