您将如何建模此应用程序？

Question

我有一个用Zend编写的MVC应用程序，它从Oracle 10g数据库中提取数据，并将这些数据显示在表和列表中，并通过颜色和图表在视觉上丰富这些数据。没有ORM，也没有创建，更新或删除，只是纯阅读。数据是从另一个应用程序插入的。DB中的数据是根据由DB视图表示和访问的概念建模的，这些视图将这些数据从其他各种表(遗留的，不能更改)聚合到一起。

| 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   |

用户可以影响视图中的列显示、排序和排序。客户端可以拒绝/允许对列的访问，并将列内容限制为某些值。用户不能覆盖客户端设置。用户是一个参与者，而客户机基本上只是一个过滤器，它为属于客户机的用户创建一个可用数据子集。持久化用户和客户端设置。

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

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中完全通用；只基于DB结构。用户当然会喜欢这个。问题是，视图必须知道很多关于数据的信息。为了丰富数据，ViewHelpers必须知道列名，而且通常是针对记录集中的多个列。它们不可能是通用的，有些东西告诉我，无论如何，这是个麻烦。感觉就像味精。我只是找不出原因。

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

Note

在接受答案之前，我将把这个问题保留一段时间。如有任何意见，我们将不胜感激。

Answer 1

再看几遍你的问题，再想一想，我相信我会这样总结一下：

你的“MVC”中缺少了"M“.

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

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

我不认为你需要移除TDG。抽象是好的。把它撕掉，让你的应用程序变得更精简，我会把它比作是走进一栋办公大楼，以员工可以使用手机为理由而撕毁电话系统。它们可以，但您不希望它们这样做，就像不希望视图直接向数据库抛出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中的$row['Status']这样的术语不同，您将拥有更安全、更简单的长期维护的$event->status。里面没有列名，只有一个属性。

现在，您在问题的最上面明确地提到，您没有任何ORM，所以我认为您可能已经意识到这其中的大部分，可能只是需要推动一下。你脑海中那些烦人的疑虑很可能是这样的:如果它并不总是只读的，那该怎么办？如果数据模型变得更加复杂怎么办？如果人们开始要求更复杂的报告呢？

所有这些都是为什么您有一个域模型，为什么它实际上是MVC的基本构建块:最终，您的用户的心智模型将与数据模型不同步，因为有许多原因我不会在这里讨论。关键是，这几乎总是发生。

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

不，我不是。只有你才能决定。我可以告诉您的是，如果没有适当的域模型，MVC模式作为一种特定的体系结构不会对您有多大好处。它稍微好一点，但并不比在每个页面中只进行内联查询或外观调用好得多。如果没有模型，MVC不过是一种花哨的URL重写方案。

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

希望这是你一直在寻找的答案！

Answer 2

DB模式设计有不同的需求(查询/写入性能、可伸缩性)作为一个很好的UI(良好的页面流，支持人们的工作方式或流程的工作方式)。因此，UI和DB方法常常很难直接映射。

作为一个糟糕的例子，我记得一个使用“Oracle Forms”的应用程序，它直接显示了数据库结构中的一个通用视图。对于非技术人员来说，使用它往往是违反直觉的。

我仍然认为，在您的情况下，如果视图可以直接映射到DB模式，那么一定要去掉不必要的抽象层、代码和简化系统。尽可能简单地实现需求。

Answer 3

为了根据用户输入动态地从表中获取数据，可以使用Zend_Dojo组件数据网格。您可以创建一个TDG对象，它将根据用户输入重新映射到新表。

http://zendguru.wordpress.com/2009/01/08/dojo-grid-in-zend-framework-creating-nice-and-cool-grid-in-php-using-zend-framework-and-dojo/