[抱歉，但工作是专有的，所以我无法提供对象的详细信息]
我正在与同事一起开发 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 的性质。 key 只会在客户端中定义，因此模型不会被污染。
他拒绝了，因为他认为模型对象应该只对域进行建模，而额外的字段与域对象无关，因此不应该添加。他认为客户应该处理这个问题。
这两种观点似乎都有优点，所以我对其他读者对此的想法/感受感兴趣。
谢谢
蒂姆
最佳答案
我认为您将数据库模型与 MVC 中的模型混淆了。请记住，MVC 模式是表示层的设计模式。模型(即 MVC 中的模型)可以是简单应用程序中的数据库模型(数据库中的实体)，但这不是必需的。
我认为您应该有一个单独的类(表模型)，正如您所说，它应该包含您在表中显示的字段。该模型将从您的业务逻辑层填充，即应该是您的 BLL 的输出。您也可以将其称为 DTO(数据传输对象)。我们的想法是只拥有您需要的数据。如果您需要计数，则只需将计数放在 DTO 中，而不是所有 Y 中。这不仅使您的应用程序易于管理，而且还减少了层之间的数据传输，从而减少了应用程序的内存占用并增加了应用程序的内存占用。性能也是如此。
关于java - 模型对象应该灵活吗，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3707392/