2

[对不起，工作是专有的，所以我不能提供对象的细节]

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

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

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

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

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

私人无效地图信息=新HashMap（）；

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

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

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

谢谢，

蒂姆

4

3 回答 3

3

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

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

于 2010-09-14T09:11:12.877 回答
1

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

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

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

于 2010-09-14T09:16:08.973 回答
0

谢谢你们的回复。

廷古 说道：

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

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

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

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

musiKk 给出了以下原因：

你永远不知道将来谁会调用该服务，所以我想尽可能地保持它的一般性。

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

优点是：

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

(2) 非常灵活，因为瞬态可以与在客户端使用的对象一起封装

缺点是：

(1) 对象越大，在网络中移动时对象越大

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

于 2010-09-14T09:49:29.507 回答