MVC 模型应该抽象到什么程度？

Question

我正在扩展和改进一个存在很多结构性问题的网站。它看起来很像我之前听说过 MVC 但不了解抽象或模块化的概念的开发人员。因此，MVC“框架”是 a) 定制 b) 损坏 c) 修补和 d) 有几个同时使用。我打算解决这个问题。

这不是我第一次重新构建网站的框架，顺便说一句，但这是我第一次不得不修复 MVC 框架。但是，我在 SO 上遇到了 MVC 知识中的一些缺失漏洞。

首先是程序员似乎将他们的 SQL 数据库与他们的模型紧密结合在一起。这对我来说没有意义：程序员通常让模型负责数据抽象吗？ （对我来说，这比将 SQL 放在原始 PHP 代码中要好一点。）或者是否有一个通常使用的“Does SQL”的数据访问层？我从经验中知道，后者意味着调用代码不必担心数据在哪里，或者如何获取数据或如何编写数据：API 会处理这些。

但是模型呢？它们是否打算在不同页面之间重复使用？他们应该关心数据的存储位置吗？他们不应该更关心处理数据获取和数据显示之间的逻辑（例如，将联系人的组 ID 转换为可显示的名称）吗？以及数据保存和数据写入（例如，弄清楚如何将 $_POST 值转换为可保存的数据）？

也许 MVC 模型真的是 DMVC - Data-Model-View-Controller。

最后，虽然这是从 PHP 的角度来看，但这些概念在 JSP 网站上的转化效果如何？

Answer 1

但是模型呢？它们是否可以在不同页面中重复使用？

是的。

他们应该只关心数据的存储位置吗？

没有。他们不必知道。所有这些信息对于持久层或数据层都是必需的。

他们不应该更关心处理数据获取和数据显示之间的逻辑（例如将联系人的组 ID 转换为可显示的名称）吗？

没有。他们只关心业务逻辑。我发现一些常见的应用程序使模型变得愚蠢，只有属性/属性，没有别的。 Java 中的典型示例是带有 getter/setter 的 POJO。我们称它们为 TO（传输对象），并在任何地方使用它们，作为数据持有者。 IMO，我并不真正同意这一点，应该有一些与业务相关的方法，这些方法是适当的并且有资格参与其中。不要让它变得如此愚蠢。新的实体 Bean (EJB3) 就是一个很好的例子。

顺便说一句，数据展示是表示层的工作。在java中JSP是视图技术的一部分。

还有数据保存和数据写入（例如，弄清楚如何将 $_POST 值转换为可保存的数据）？

没有。这通常在我们的控制器中完成，大部分时间使用一些实用程序类。

Answer 2

您会在此处找到多个关于是从数据库架构还是从用户界面开始工作的话题。有一个地方可以看。

我能想到的工具不止一种，它采用模式并为您构建 CRUD UI（“脚手架”），反之亦然。还有一个地方可以看。 （典型代表：Ruby on Rails 及其认知后代）。

在讨论 ORM 工具时，有太多次（但绝不是全部）首选的首字母缩写词是“ROM”。

我们有很多工具可以鼓励我们“准备好，开火，瞄准”的邪恶倾向。对于管理来说，它是“Proof of Concept”和“RC1”之间最短的一条线。