2

初始情况：

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

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

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

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

4

2 回答 2

6

我总是在服务层的任何实际工作都在控制器中完成的基础上工作。

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

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

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

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

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

于 2012-12-19T17:44:36.013 回答
1

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

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

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

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

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

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

于 2012-12-19T17:56:12.273 回答