MVC：我应该把这个数据访问逻辑放在哪里？

Question

在家里重建个人Web应用程序时，我一直试图坚持对MVC的严格解释，但是我遇到了一些问题。

该应用程序是财务跟踪应用程序。我停留在第一页上，该页面只是该月银行帐户交易的列表。交易清单是我的模型。此时，可以很容易地想到Controller和View。

但是，我在页面顶部还有两个按钮。它们是箭头，一个对应于上个月的箭头，另一个对应于下个月的交易列表。如果上个月/下个月没有交易，我不希望启用这些按钮，因此我需要与数据库进行对话，以确定每个按钮是否应该实际链接到某个地方。

从我所读的大部分内容来看，应尽可能将数据库访问封装在模型中，而在Controllers和Views中则几乎没有数据库访问。

但是，这些按钮本质上需要询问数据库：“下个月/前几个月是否有任何交易？” 答案将确定是否禁用了它们的链接，以及将用户发送到何处。

严格来说，将其逻辑放入“事务列表”模型似乎不合适，因为是否存在超出请求范围的事务不在事务列表模型的考虑范围之内。

我想我也可以创建另一个模型，该模型对应于存在交易的所有年月组合。然后，我可以将此模型和事务列表传递给正确的视图。

还是我应该偏离“无数据库访问外部”模型范式，而只是向视图中抛出一些快速的数据库查询（因为结果本质上是一个UI问题，使导航更加容易）？

你们如何看待这个概念性问题？

顺便说一句，我没有使用任何框架。这是一个宠物项目，旨在使我更加熟悉MVC模式的细节。

Answer 1

...我是否应该偏离模型之外的无数据库访问范例，而只是将一些快速数据库查询放入视图中...

最简洁的答案是不。如果您确实对学习 MVC 和更好的编码感兴趣，那么“仅仅因为”就走捷径是一个非常糟糕的主意。域逻辑分离是 MVC 的一个基本概念，违反它本质上就是从 MVC 转移到由糟糕的代码和“MVC 框架”主导的领域。如果您想学习“MVC 的具体细节”，您就必须了解具体细节就像关注点分离一样，而且它们非常重要。

您问题中的很多文本都提出了一些关于模型应该是什么的混合想法，因此我将把您重定向到有关 MVC 模型的最相关的答案。这个答案包含了您想了解的有关模型概念的所有内容。总结其中最重要的概念，模型不是一个类，而是一个层。模型层有许多组件，它们都做自己的事情，这给您留下了可测试的、可扩展的、语义的和逻辑域逻辑层。

请记住要小心：关于 MVC 的错误信息比可靠信息要多得多。要学习正确的 MVC，最糟糕的事情就是查看自称是 MVC 的框架的内部。

编辑：我在回复时假设语言是 PHP，所以我的一些答案可能反映了这个假设。然而，这些概念几乎适用于所有语言