模型对象是否应该灵活

Question

[抱歉，工作是专有的，所以我不能提供对象的详细信息]

我正在与一位同事一起开发 Java 应用程序。我在做客户端，他在写服务端代码。

应用程序显示一个 X 对象表。表中的列显示了 X 的一些属性。此外，我们有一列显示每个 X 的 Y 计数。（关联是 Y 到 X 的多对一，一种方式是，Y 引用其父 X）。

Y 的计数不是 X 的属性，而是通过对 DB 的查询获得的。

我使用的是 TableModel，因此使用 X 对象作为表格的模型显然会更容易。但由于 Y 计数不是 X 的属性，我需要创建一个容器对象来保存 X 和计数。这很烦人，因为它添加了一个似乎不必要的类。

我建议我的同事在 X 中添加一个额外的字段和一个 getter：

private void Map info = new HashMap();

这将使模型对象 X 更加灵活。我可以随时在客户端中存储我需要的任何状态，而不会影响模型的主要属性，这些属性特定于 X 的性质。键只会在客户端中定义，因此模型不会被污染。

他拒绝了，因为他认为模型对象应该只对领域进行建模，而额外的字段与领域对象无关，因此不应该添加。他认为客户应该处理这个问题。

这两种观点似乎都有优点，所以我会对其他读者对此的看法/感受感兴趣。

谢谢，

提姆

Answer 1

谢谢大家的回复。

廷古说：

我认为您混淆了数据库 模型与 MVC 中的模型

好的，是的。所以你是说实际上有两种不同的模型对象，一种用于数据库，另一种用于客户端应用程序中 MVC 中的 M，并且客户端模型由检索到的数据库模型对象中的 BLL 填充？

musiKk 在我的阅读中也说了同样的话。

我们在客户端使用服务器端模型作为数据模型（MVC M），对象很简单。

musiKk 给出了以下理由：

你永远不知道谁会打电话给 未来的服务所以我想 尽量笼统。

这正是我同事提出的论点。我完全同意这是必不可少的。然而，我的想法是，向模型添加对象映射绝不会使模型不那么通用。它是为了方便客户而提供的，是一张空地图。

优点是：

(1) 客户端无需为像这样的简单案例创建子类或创建新对象，只需一个额外的字段

(2) 非常灵活，因为瞬态可以在客户端中使用对象进行封装

缺点是：

(1) 物体越大，在网络中移动时也越大

(2) 如果你子类化你有额外的字段，即使你不使用它

Answer 2

我处于完全相同的位置（我主要是服务器端的人），我认为它就像你的同事。

在我们的例子中，服务器端是一个网络服务。您永远不知道将来谁会调用该服务，因此我希望尽可能保持通用。每当我们需要模型中的特殊数据时，我们都会扩展适当的类并以这种方式添加它们。通常这是不费吹灰之力的，因为无论如何我们都需要子类化（例如，在 MVC 的许多类中，我们需要 PropertyChangeSupport）。

但是我不知道这是否解决了您的“计数”示例。我们也遇到了类似的情况，我刚刚创建了一个特殊的 DTO，因为 user446612 建议它保存数据。

Answer 3

我认为您将数据库模型与 MVC 中的模型混淆了。请记住，MVC 模式是表示层的设计模式。模型，即 MVC 中的模型可以是简单应用程序中的数据库模型（数据库中的实体），但这不是必需的。

我认为您应该有一个单独的类（表格模型），如您所说，它应该包含您在表格中显示的字段。该模型将从您的业务逻辑层填充，即应该是您的 BLL 的输出。您也可以将其称为 DTO（数据传输对象）。这个想法是只拥有您需要的数据。如果您需要计数，则只需在 DTO 中计数而不是所有 Y。这不仅会使您的应用程序易于管理，而且还可以减少数据传输而不是层之间的数据传输，从而减少应用程序的内存占用并增加性能也是如此。