php - 您将如何为这个应用程序建模？

Question

我有一个用 Zend Framework 编写的 MVC 应用程序，它从 Oracle 10g 数据库中提取数据并将这些数据显示在表格和列表中，并通过颜色和图表直观地丰富这些数据。没有 ORM，也没有涉及创建、更新或删除，只是纯粹的阅读。数据是从另一个应用程序插入的。数据库中的数据是根据它们所代表的概念建模的，并由数据库 View 访问，这些 View 从各种其他表(遗留的，无法更改的)聚合这些数据，例如

| Event ID | Start               | End                 | Status | Created_By |
-----------------------------------------------------------------------------
| 12345678 | 2009-10-01 12:00:00 | 2009-10-01 12:15:00 | booked | John Doe   |
| 12345679 | 2009-11-01 13:00:00 | 2009-12-01 12:00:00 | booked | John Doe   |
| 12345680 | 2009-11-01 13:00:00 | 2009-12-01 12:00:00 | tba    | Jane Doe   |

用户可以从 View 中影响列显示、排序和排序。客户端可以拒绝/允许访问列并将列内容限制为特定值。用户无法覆盖客户端设置。用户是一个参与者，而客户端基本上只是一个过滤器，它为属于客户端的用户创建可用数据的子集。保留用户和客户端设置。

我目前的做法大致是这样的:

Request --> Controller
            | <--> sanitizes and returns Request params
            | ---> Facade (capsules steps to fetch View Data)
            |      | <--> Table Data Gateway builds Query for requested View
            |      | <--> Query Decorator¹ applies User/Client settings
            |      | <--> DB Adapter fetches RecordSet from decorated Query
            | <----returns Recordset
            | <--> applies RecordSet to View
            | <--> Data-Aware ViewHelper render RecordSet (and View)
Response <--returns rendered View

¹ 查询装饰器可以读取持久化的用户/客户端设置，并将其添加到 TDG 动态返回的基本查询对象中。

但是，最近我一直怀疑这种方法并想改进它。我想我可以完全删除 TDG，并从 UI 中构建完全通用的 View ；仅基于数据库结构。用户肯定会喜欢这个。问题是，View 必须了解很多关于数据的信息。 ViewHelpers 必须知道列名才能丰富数据，而且它们通常对 Recordsets 中的多个列这样做。它们不能是通用的，有些东西告诉我这无论如何都是麻烦的。感觉就像大杂烩。我只是无法确定原因。

非常感谢任何模式、想法和意见。我知道这个问题有些含糊，但正如我所说，我无法确定是什么让我怀疑这种方法。所以我想我正在寻找任何好的实践方法来以可维护的方式构建用户和客户端可定制的以数据库为中心的应用程序。我当然不需要解决方案，只需要一些想法和一些链接，看看其他人是如何解决这个问题的，这样我就可以在下一次重构时考虑到它。

注意
在接受答案之前，我会将问题一直悬而未决。感谢任何输入。

Answer 1

在重新阅读你的问题几次并稍微反射(reflection)之后，我相信我会这样总结情况:

您的“MVC”中缺少“M”。

此时，您已经手工制作了一个关系数据库架构，使其与您的领域模型具有 1:1 的映射关系。这很好，它使映射变得非常容易，但记录集仍然不是域类。

MVC 上下文中的术语模型 指的是域模型，而不是关系模型。如果你有一个关系数据库支持这个应用程序，那么你需要某种映射。这并不是说您需要像 Doctrine 这样的成熟的 ORM 框架——尽管我确实发现这些工具让我的生活变得更轻松，即使对于小型项目也是如此——但你需要一些东西。事实上，Zend Framework 甚至在 Quick Start 中详细介绍了映射领域模型的细节。 .

我认为您不需要删除 TDG。抽象是好的。拆掉它以使您的应用程序更精简一点，我将其比作进入办公大楼并拆掉电话系统，理由是员工只能使用他们的手机。它们可以，但您不希望它们这样做，就像您不希望您的 View 直接向数据库抛出 SQL 查询一样。它效率低下且通常难以管理。

我的架构版本如下所示:

Request --> Controller
            | <--> sanitizes and returns Request params
            | ---> Facade (encapsulates steps to fetch View Data)
            |      | <--> Table Data Gateway builds Query for requested View
            |      | <--> Query Decorator applies User/Client settings
            |      | <--> DB Adapter fetches RecordSet from decorated Query
***         |      | <--> Mapping layer converts RecordSet to Domain Model
***         | <----returns Model
***         | <--> applies Model to View
***         | <--> Data-Aware ViewHelper render Model (and View)
Response <--returns rendered View

我用 *** 标记了更改行。实际上，我唯一改变的是，它不是从外观中获取记录集，而是获取模型(可能是域类数组)，并将 那个 应用到 View 。

您的 View [Helper] 中没有像 $row['Status'] 这样的术语，您将拥有 $event->status，这更安全、更简单以长期维持。那里没有列名，只有一个属性。

现在您在问题的最顶部明确提到您没有任何 ORM，所以我认为您可能已经了解其中的大部分内容，并且可能只需要插入一下。您脑子里那些挥之不去的疑虑可能是这样的:如果它不总是只读的怎么办？如果数据模型变得更复杂怎么办？如果人们开始要求更复杂的报告怎么办？

所有这些都是你拥有领域模型的原因，为什么它实际上是 MVC 的基本构建 block :最终，你的用户拥有的心智模型将与数据模型，出于多种原因，我不会在这里讨论。关键是，它几乎总是会发生。

我确定这是必要的吗？我是否肯定这不仅仅是矫枉过正，一堆对这么小的项目毫无意义的仪式咒语？

不，我不是。只有你能决定。我可以告诉您的是，如果没有适当的域模型，作为特定 体系结构的 MVC 范例对您没有多大用处。它比在每个页面中仅进行内联查询或外观调用要好一些，但那也好不了多少。如果没有模型，MVC 只不过是一种奇特的 URL 重写方案。

也许您需要这种抽象级别，也许您不需要；但我猜你可能怀疑你可能会，否则你不会问这个问题。想一想，分析当前的需求和范围，问问自己可能发生什么样的变化，如果当前的架构看起来太脆弱而无法适应，那么下一个合乎逻辑的步骤将是领域模型——即使今天 它只是关系模型的精确镜像。明天可能就不是了。

希望这就是您正在寻找的答案!