我的Asp.Net MVC 4应用程序中的模型应该是愚蠢的吗？

Question

我已经读过我的模型应该只是数据的愚蠢容器，这种吸引力。 如果是这种情况，那么我的理解是控制器调用Repository，它只会填充模型并将其传回去。

        using (var userRepo = new UserRepository())
        {
            var users = userRepo.GetAll();
            return View(users);
        }

如果我想添加一个类似AlertUserOrderHasBeenRecd（）的方法，我会把它放在哪里？

如果我把它放入Repository，那么Repository所做的不仅仅是Data Persistence。

如果我将它放入模型中，那么模型就不再是一个愚蠢的数据容器。

我还可以添加一个在订单模型和用户模型中传递的附加类，并在不了解EF的情况下执行操作。

或者别的什么。

是否有一种普遍接受的最佳处理方式？

Answer 1

此方法可以在服务层中定义。服务层依赖于存储库，因为它包含可以由存储库中的多个CRUD操作组成的业务操作。然后，您的控制器将采用服务层而不是存储库，并在其上调用业务方法。

作为向您的应用程序引入另一个抽象层的替代方法，您可以favor query objects over repositories。

Answer 2

我在分离模型和ViewModel方面有非常好的结果。 ViewModel只是数据（DTO）的哑容器。模型是业务层（UI的业务）。所以，结果是：

• 控制器：处理网站导航。
• 模型：填充并处理Controller请求的ViewModel。
• ViewModel：DTO包含将要表示的数据。
• 查看：ViewModel中数据的直观表示。

在这种架构中，您的方法将在模型中。