Java 模型对象应该是灵活的吗

[很抱歉，作品是专有的，因此我无法提供对象的详细信息]

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

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

Y的计数不是X的属性，而是通过数据库上的查询获得的

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

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

private void Map info=new HashMap（）

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

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

这两种观点似乎都有优点，所以我想了解其他读者对此的看法

谢谢

---

Tim

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

---

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

我也处于完全相同的位置（我主要是服务器端的人）我和你的同事一样看待它

在我们的例子中，服务器端是一个web服务。你永远不知道将来谁会调用该服务，所以我希望尽可能地将其保持为通用的。每当我们需要模型中的特殊数据时，我们都会扩展相应的类，并以这种方式添加它们。通常这是一个不需要思考的问题，因为我们无论如何都需要子类（例如，在MVC的许多类中，我们需要

PropertyChangeSupport

）

---

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

感谢您的回复

廷古说,

---

我想你把数据库弄糊涂了 模型与MVC中的模型

好的，是的。那么您是说实际上有两个不同的模型对象，一个用于数据库，一个用于客户端应用程序中的MVC中的M，客户端模型由检索到的数据库模型对象中的BLL填充

通过我的阅读，Musik也在说同样的话

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

Musik给出了以下理由：

你永远不知道谁会打电话给 未来的服务，所以我想 尽可能保持它的概括性

这正是我的同事提出的论点。我完全同意这一点。然而，我的想法是，在模型中添加对象映射绝不会降低模型的通用性。它是为方便客户而提供的，是一个空映射

优点是：

（1） 通过一个额外的字段，使客户端不必为这样的简单情况创建子类或创建新对象

（2） 非常灵活，因为在客户机中使用对象时，可以使用对象封装瞬态

缺点是：

（1） 对象越大，在网络中移动时越大

---

（2） 如果你将其子类化，即使你不使用它，你也会有额外的字段。我看到很多人将MVC作为应用程序中所有层的模式（这是一个误解）。如果有更改，你应该更新你的问题。论坛也不是这样。你将更新作为答案发布。