模型对象应该是灵活的

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模式是表示层的设计模式。模型，即在MVC中可以是简单应用程序中的数据库模型（数据库中的实体），但这不是必需的。

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

Answer 2

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

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

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

Answer 3

感谢你们的回复。

Tingu说：

  

我认为你让数据库感到困惑   模型与MVC中的模型

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

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

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

musiKk给出了以下理由：

  

你永远不知道谁会打电话给你   我希望将来服务   保持尽可能一般。

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

优点是：

（1）保存客户端必须创建子类或为一个简单的情况创建新对象，只需一个额外的字段

（2）非常灵活，因为瞬态可以用客户端

中的对象封装

缺点是：

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

（2）如果你是子类，即使你不使用它也有额外的字段