我正在扩展和改进一个存在很多结构问题的网站。它看起来很像我之前的开发人员听说过 MVC 但不理解抽象或模块化的思想。所以 MVC“框架”是 a) 定制的 b) 损坏的 c) 修补的和 d) 有几个同时使用。我打算解决这个问题。
这不是我第一次重新构建站点的框架，顺便说一句，但这是我第一次不得不修复 MVC 框架。但是，我在 SO 上遇到了 MVC 知识中的一些缺失漏洞。
首先是程序员似乎将他们的 SQL 数据库与他们的模型紧密联系在一起。这对我来说没有意义:程序员通常让模型负责数据抽象吗？ (对我来说，这比将 SQL 放入原始 PHP 代码中好不了多少。)或者是否存在通常采用“执行 SQL”的数据访问层？我从经验中知道，后者意味着调用代码不必担心数据在哪里、如何获取数据或如何编写数据:API 会处理这些问题。
但是模型呢？它们是否打算在不同页面之间重复使用？他们应该只关心数据存储在哪里吗？他们不应该更关心处理数据获取和数据显示之间的逻辑(例如，将联系人的组 ID 转换为可显示的名称)吗？以及数据保存和数据写入(例如弄清楚如何将 $_POST 值转换为可保存数据)？
也许 MVC 模型真的是 DMVC - Data-Model-View-Controller。
最后，尽管这是从 PHP 的角度来看的，但这些概念在 JSP 站点中的转化效果如何？
最佳答案
但是模型呢？它们是否打算在不同页面之间重复使用？
是的。
他们应该只关心数据的存储位置吗？
没有。他们不需要知道。所有这些信息对于持久层或数据层都是必需的。
他们不应该更关心处理数据获取和数据显示之间的逻辑(例如，将联系人的组 ID 转换为可显示的名称)吗？
没有。他们只关心业务逻辑。我发现一些常用的应用程序使模型变得愚蠢，只有属性/属性，没有别的。 Java 中的典型示例是带有 getter/setter 的 POJO。我们称它们为 TO(传输对象)，并将它们作为数据持有者随处使用。我并不是真的同意这一点，IMO，应该有一些方法，与业务相关，这些方法是合适的并且有资格包含在其中。别让它这么蠢。新的 Entity Beans (EJB3) 就是一个很好的例子。
顺便说一句，数据展示是表现层的工作。在java中JSP是 View 技术的一部分。
以及数据保存和数据写入(例如弄清楚如何将 $_POST 值转换为可保存数据)？
没有。这通常在我们的 Controller 中完成，大部分时间使用一些实用程序类。
关于java - MVC 模型应该抽象到什么程度？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/351470/