使用MVC时，我应该在哪里添加一个List All Users函数？

Question

我知道，在model-view-controller，模型是类的一部分。

如果我有一个用户类并实例化一个对象，则该对象必须引用数据库中的单个用户。

因此，我将在该用户上为该特定用户提供CRUD方法。

但是，如果我需要一个函数来运行SELECT * FROM Users，我应该在用户类中创建一个函数吗？或者帮助文件中的函数？或者在控制器中？为了尊重MVC模式，它应该去哪里？

我的意思是，实例化User对象只是为了运行一个显示Users表的函数是没有意义的。

---

^{我不知道这是否会提高“主要基于意见”的标志。我只是不知道这些功能应该放在哪里。如果你们认为这个问题值得关闭，那没问题。但是在我要问这个问题的堆栈社区的评论中告诉我。}

Answer 1

我会使用某种'存储库'层。然后，我的控制器调用UserRepository的GetAll方法并将数据发送到View层。

Answer 2

备份一下。让我们暂时基础一下。

在MVC模式

• 模型就是你的状态（简单计算），这意味着你用
• 视图工作业务功能的重要数据的表示是一种表现方式国家给用户（这里要注意的用户可以是另一个系统，你可以使用的服务端点MVC模式）
• 控制器保证了模型得到的视图，并背出视图

在设计有良好状态分离的系统中，业务功能不存在于模型，视图或控制器中。您将业务功能分隔到自己的类库中。为什么？你永远不知道应用何时需要移动（本地，而不是web）实现或桌面实现，或者甚至可能成为Windows服务的一部分。

至于获取数据，正确分离关注点表明数据访问不仅与模型，视图和控制器分开，还与业务功能分开。这就是DAL创建的原因。

在继续之前，让我们回到您的问题。

我应该在User类中创建一个函数吗？这是一种“积极的记录”模式，如今它在很大程度上被弃用，因为它将行为和状态紧密结合在一起。我确定仍然有一些情况适用，但我不会使用它。

或者帮助文件中的函数？更好的选择，因为你可以分开它。但我个人并不喜欢“单一项目中的所有事情”。

还是在控制器中？从来没有，尽管斯科特顾的第一个MVC例子，他把LINQ to SQL（另一个呻吟？）在控制器中。

它应该去哪里，为了尊重MVC模式？

这里是我的建议：

• 创建一个DAL项目来访问数据。在这里很好地工作的一种可能的模式是存储库模式。如果您在所有/大多数表中为键使用相同的数据类型，则可以创建一个通用存储库，然后为特定数据导出单个版本。好的，所以这个版本真的很老了，但是仔细看，它仍然有高级概念（https://gregorybeamer.wordpress.com/2010/08/10/generics-on-the-data-access-layer）
• 如果需要，为业务逻辑创建一个核心项目。我每次都这样做，因为它允许我通过单元测试来测试DAL上的想法。是的，我可以直接在MVC项目中进行测试（并且可以），但我喜欢彻底的分离，因为您很少在解决方案中找到0％的业务规则。
• 让核心从DAL项目中获取数据，而MVC项目使用核心项目。好的流量。易于单元测试。等

如果你想在一个单独的项目中，然后将这些位分成不同的文件夹，所以你可以在未来需要的时候创建单独的项目。

Answer 3

对于所有善良和圣洁的事物的爱，不要使用存储库模式。 @GregoryABeamer在各方面都有很好的答案，除了建议您创建存储库实例来访问您的实体。你的ORM（最可能的实体框架）涵盖了这个，并且完全替代了知识库和工作单元的概念。

简而言之，如果您需要数据库中的某些内容，请直接在您的控制器中打开ORM。如果你愿意，你仍然可以添加一个抽象级别来隐藏ORM本身的使用，这样你就可以更容易地用另一个ORM，Web Api等来切换数据访问。只是不要做一个传统的单元与数十或数百个存储库实例一起工作。如果你有兴趣，你可以read a series of posts I wrote about that on my blog。我用我的方法使用术语“存储库”，但主要只是为了与您发现遍布整个互联网的典型“通用”存储库方法形成对比。