具有微小逻辑的小型网站的简单模型层

Question

由于我不是php开发人员，因此我在php中长期以来一直在努力使用MVC概念。我重复了几次我的网站，但它仍然看起来像一个指向蚊子的大炮。我已经阅读了很多关于MVC的文章，帖子和回答，但它仍让我感到困惑。

让我们拥有一个包含文章和评论系统的简单网站。一切都直接存储在数据库中（有关文章，路径，评论等的信息）。主要基于this我使用MVC开发了自己的应用程序。以下是它的工作原理：

1. Controller从数据库中检索有关文章和相关评论的数据
2. 创建所需模型的对象（当前文章和评论）
3. ...然后将必要的数据传递给View
4. View通过应用提供的对象的特定模板来显示这些数据

一切都像魅力一样......但

• 我的模型对象不需要任何外部逻辑，因此我的域对象与getter / setter类接壤 - 我想知道：我是否需要域对象？存储分离的对象仅仅是为了让它们从数据库中获取并在一段时间后在网站上显示是没有意义的，不是吗？
• controller保存传递给服务和映射器的数据库连接，用于创建模型的对象 - 但是映射器中存储的查询可以合并到服务功能中

总之，我想知道用单个管理器（每个对象）替换三部分模型是不是更好的方法，它将从数据库中检索所有必要的数据，并以任何方式和形式传递它们（即关联数组）到视图。

请注意，我正在描述一个具有微小逻辑的简单案例（1：1：1），其中从数据库检索的大多数数据仅用于演示目的。

Answer 1

您刚才描述的是数据建模的架构模式，称为数据映射器模式。

在此模式中，您将持久性逻辑分离到Mapper类，并将所有数据内容保留在域模型中。在您的场景中，您提到的逻辑很少，这很好。随着应用程序的成熟，逻辑也会增长关键点是分离，持久性与逻辑无关，因此应该转移到另一个类中。

Mapper类只关注持久化数据（通常是你选择的任何数据存储），实际上你使用＆＃34; Adapters＆＃34;，这就是为什么在某些ORM中你会看到不同的数据存储适配器的原因（即MySQLAdapater与PostGresAdapater等，实现抽象的适配器接口/基类）。

应该注意的是，在您的结论中，您所描述的实际上是MVC架构。

模型层本质上是您的持久层（如上所述） 视图层是您显示数据的位置。 您的控制器层是数据操作的位置，即您的域对象的数据。

通常MVC请求就像...... URI被映射到controller :: action Action获取数据，对其进行操作并将其发送到视图进行渲染。

当MVC应用程序遇到麻烦时，您的Controller会访问多个不同的对象并需要将它们全部保留。 MVC应用程序的类体系结构往往非常繁重，因为模型通常比Data Mapper模式具有更多的逻辑，因为MVC模型将持久性绑定到它们中（实际上）。

除此之外，对于像您这样的简单项目，您可能希望查看简单的表示框架，例如http://www.slimframework.com/它没有内置的持久层，这使您可以选择最适合您的项目。