模型对象应该灵活吗
[抱歉，但工作是专有的，所以我无法提供对象的详细信息]
我正在与同事一起开发 Java 应用程序。我做客户端，他写服务端代码。
该应用程序显示 X 对象的表。表的列显示了 X 的一些属性。此外，我们有一列显示每个 X 的 Y 计数。（关联是 Y 到 X 的多对一，并且 Y 具有对其父 X 的引用）。
Y 的计数不是 X 的属性，而是通过 DB 查询获得的。
我正在使用 TableModel，因此使用 X 对象作为表的模型显然会更容易。但由于 Y 计数不是 XI 的属性，因此我需要创建一个容器对象来保存 X 和计数。这相当烦人，因为它添加了一个似乎不必要的类。
我建议我的同事给 X 添加一个额外的字段和一个 getter：
private void Map info = new HashMap();
这将使模型对象 X 更加灵活。我可以随时在客户端中存储我需要的任何状态，而不会影响模型的主要属性，这些属性特定于 X 的性质。键只会在客户端中定义，因此模型不会被污染。
他拒绝了，因为他认为模型对象应该只对域进行建模，而额外的字段与域对象无关，因此不应该添加。他认为客户应该处理这个问题。
这两种观点似乎都有优点，所以我对其他读者对此的想法/感受感兴趣。
谢谢，
蒂姆
[Sorry but work is proprietary so I cannot give details of objects]
I am working on a Java application with a colleague. I am doing the client side and he is writing the server code.
The application displays a table of X objects. The columns of the table show some of X's attributes. In addition we have a column that shows a count of Y for each X. (Association is many-to-one Y to X and one way, Y has a reference to its parent X).
The count of Y is not an attribute of X but is obtained via a query on the DB.
I am using a TableModel so it would obviously be easier to use X objects as the model for the table. But since the Y count is not an attribute of X I will need to create a container object to hold an X plus a count. This is rather annoying as it adds a class that seems unnecessary.
I suggested to my colleague that he add an extra field to X plus a getter:
private void Map info = new HashMap();
This would make the model objects X more flexible. I can store any state I need at any time in the client without affecting the main attributes of the model which are specific to the nature of X. The keys would only be defined in the client so the model would not be polluted.
He has refused because he feels that the model objects should only model the domain and the extra field is not related to the domain objects and so should not be added. He thinks that the client should handle this.
Both viewpoints seem to have merit so I would be interested in what other readers think/feel about this.
Thanks,
Tim
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为您将数据库模型与 MVC 中的模型混淆了。请记住，MVC 模式是表示层的设计模式。 MVC 中的模型可以是简单应用程序中的数据库模型（数据库中的实体），但这不是必需的。
我认为您应该有一个单独的类（表模型），正如您所说，它应该包含您在表中显示的字段。该模型将从您的业务逻辑层填充，即应该是 BLL 的输出。您也可以将其称为 DTO（数据传输对象）。我们的想法是只拥有您需要的数据。如果您需要计数，则只需将计数放在 DTO 中，而不是所有 Y 中。这不仅使您的应用程序易于管理，而且还减少了层之间的数据传输，从而减少了应用程序的内存占用并增加了应用程序的内存占用。性能也是如此。
I think you are confusing the database model with the Model in MVC. Keep in mind that the MVC pattern is a design pattern for presentation layer. The Model i.e., in MVC can be the database model (entities in database) in a simplistic application but that is not necessary.
I my opinion you should have a separate class (Table Model) as you said which should contain the fields that you are displaying in the Table. This model will get populated from you Business Logic Layer i.e., should be the output of your BLL. You can also term this as a DTO (Data Transfer Object). The idea is to have only the data that you need. If you need the count then only have the count in the DTO instead of all of the Y. This will not only make your application manageable but also reduce the data transfer than goes on between the layers hence reducing the memory footprint of your application and increasing the performance as well.
我处于完全相同的位置（我主要是服务器端人员），我的看法就像你的同事一样。
在我们的例子中，服务器端是一个 Web 服务。您永远不知道将来谁会调用该服务，因此我希望尽可能使其通用。每当我们在模型中需要特殊数据时，我们都会扩展适当的类并以这种方式添加它们。通常这很容易，因为我们无论如何都需要子类化（例如，我们在 MVC 的许多类中都需要
PropertyChangeSupport）。但是我不知道这是否可以解决您的“计数”示例。我们也遇到了类似的情况，我刚刚创建了一个特殊的 DTO 作为 user446612 表示保存数据。
I'm in exactly the same position (I'm mostly the server side guy) and I see it like your colleague.
In our case the server side is a web service. You never know who will be calling the service in the future so I want to keep it as general as possible. Whenever we need special data in the model we extend the appropriate classes and add them this way. Often this is a no brainer since we need to subclass anyway (e.g. we need
PropertyChangeSupportin a lot of the classes for MVC).However I don't know if this solves your 'count' example. We also encountered a similar situation and I just created a special DTO as user446612 suggests that holds the data.
谢谢你们的回复。
廷古说道：
好的，是的。那么您的意思是，实际上存在两种不同的模型对象，一种用于数据库，一种用于客户端应用程序中 MVC 中的 M，并且客户端模型由检索到的数据库模型对象中的 BLL 填充？
musiKk 通过我的阅读也表达了同样的意思。
我们使用服务器端模型作为客户端中的数据模型（MVC M），并且对象很简单。
musiKk 给出了以下理由：
这正是我的同事提出的论点。我完全同意这是必要的。然而，我的想法是，向模型添加对象映射绝不会降低模型的通用性。它是为了方便客户而提供的，并且是一张空地图。
优点是：
(1) 使客户端不必为像这样的简单情况使用单个额外字段创建子类或创建新对象
(2) 非常灵活，因为在客户端中使用时可以用对象封装瞬态
缺点是：
（1）对象更大，这使得在网络上移动时对象更大
（2）如果你子类化，即使你不使用它，你也会有额外的字段
Thank you for the responses guys.
Tingu said:
Okay yes. So you are saying that there are effectively two different model objects, one for the database and one for the M in MVC in the client application, and that the client side model is populated by the BLL from the retrieved database model objects?
musiKk is saying the same thing by my reading.
We are using the server side model as the data model (MVC M) in the client and the objects are simple.
musiKk gave the following reason:
This is exactly argument put forward by my colleague. I completely agree that this is essential. However my thought here was that adding a map of object to the model in no way makes the model less general. It is provided as a convenience to the client and is an empty map.
The advantages are:
(1) saves the client having to create subclasses or create new objects for a simple case like this with a single extra field
(2) very flexible as transient state can be encapsulated with the object as it is used in the client
The disadvantages are:
(1) objects are bigger which makes it larger when moving across the network
(2) if you subclass you have the extra field even if you don't use it