在控制器中做出任何形式的商业决策是错误的吗？

Question

我正在使用ASP.NET MVC 5构建一个原型web应用程序。应用程序的一部分是显示一个记录网格，每个记录都有一个按钮操作来保存该记录。另一页显示存档的记录。WCF服务提供模型和持久性。

我已经为每个页面构建了一个控制器，在每个控制器中，我检索所有的记录，然后选择当前或存档的记录并只显示这些记录。在当前记录控制器上有一种额外的方法来设置记录的存档状态，然后重新显示当前记录。

我怀疑这是一个潜在的糟糕的设计，因为业务决策是在控制器而不是模型中进行的。我应该在MVC应用程序中创建一个模型“层”，其方法是根据需要返回当前记录或存档记录，或者更新记录状态，从而“包装”WCF服务，还是在不必要的情况下增加一层复杂性？

基于MVC概念的纯粹决策是什么？是否应该在模型中而不是在控制器中做出任何业务决策(甚至像基于状态的过滤记录那样简单)？

Answer 1

我不使用ASP.Net，但是当涉及到MVC时，我喜欢将所有的层都清晰地分开。

最好将域模型从持久化层中分离出来，以便在需要时可以轻松地提供另一个模型。在我看来，域模型应该只包含基本属性和方法。涉及处理的方法，即使是最简单的方法，也应该在业务对象中实现。控制器在某种程度上与MVC框架相关，另一方面，您希望您的服务层独立于它。

尽管如此，在您的情况下，如果不涉及任何额外的处理，过滤也可以位于持久性层。

如果setArchiveStatus方法不涉及进一步的处理，并且它只是一个域模型属性，则该方法可以位于模型中。

Answer 2

通常，您需要以RESTful方式处理请求的瘦控制器，其中包含模型中的任何业务逻辑。

我会把任何状态相关的东西，如登录用户和任何请求相关的东西，如‘该用户的记录’在控制器中。

我会将特定于当前记录或存档记录的数据库调用作为方法放在模型中，然后从控制器调用这些方法。