我正在实现一种数据库搜索算法，该算法搜索 MongoDB 中的许多集合，并根据整个数据库的状态返回优化的结果。我对实现没有任何问题，但是命名法和我应该如何构建文件系统让我很烦。我应该在模型-视图-控制器模式的哪个位置放置只读操作？是服务吗？它有一个控制器，但我认为它几乎不符合成为模型的标准。
【问题讨论】：
标签： mongodb model-view-controller computer-science computer-science-theory
这个问题非常依赖于语言以及该语言中存在的功能。我将从 PHP 的角度讲。
搜索功能应该进入模型，模型作为 MVC 模式中的数据提供者备份。一个单独的中心点，从中可以自行分发它的实例。
一些 MVC 实现了所谓的factory 类。它们专门设计为位于 MVC 正常模式之外，以便能够提供数据：http://en.wikipedia.org/wiki/Factory_method_pattern。作为使用过这种模式的人，我可以说它很快变得复杂且难以管理。这就是为什么我更喜欢将模型作为数据提供者本身进行备份，它只需要类组织。
【讨论】：
模型视图控制器架构几乎相当于客户端服务器设置中的三层或四层解决方案，并且适用相同的规则。
复杂而密集的数据库功能与最适合该任务且最可重用的工具一起使用，在这种情况下，我认为 RDBMS 将是绝大多数 RDBMS 中的最佳选择，因为它是最了解如何操作数据、制定查询计划等的 RDBMS...
也可以说，从纯粹编码的角度来看，模型层是最自然的地方，您可以在一层中访问所有数据。
将这种功能放置在可重用性最低的层（即控制器/视图）中是不太可能的
这当然只是我的意见，我怀疑你会得到很多不同的意见，但是（我不能认为从性能的角度来看 yopur 逻辑属于数据库级别以外的任何地方
更新
模型是所有数据的守护者。如果视图或控制器需要数据，它会向模型询问该数据。视图或控制器不应该关心数据是如何获得的或来自哪里的。这是关于关注点分离。所以这就留下了问题。我将查询数据库的代码放在模型中还是 RDBMS 中？
当然，您必须首先在模型中拥有一个方法，以便视图或控制器首先调用，所以您当然需要一个模型，但该方法内部的内容以及实际查询 SQL 所在的位置取决于设计师。关键是，只要查询存在于模型或数据库级别，您就可以从视图或控制器中隐藏实现，并且可以随时随意更改实现，而不必担心可能调用它的许多地方。
所以模型或 RDBMS 是答案。选择的解决方案取决于您使用的 MVC 工具和您使用的 RDBMS。另请记住，模型不必由单一方法组成，这是您暗示您可能会从您的评论中思考的方法。
【讨论】：