传输对象是否应该始终反映整个数据库行条目？
我有一个关于 DAO 模式中传输对象的问题。假设您有一个 USER 表，该表中有 20 个字段。在业务逻辑中，我注意到在某些场景中可能需要字段1到字段3，在其他场景中可能需要字段4 - 字段6。因此，当我实现 userTO 类时，我应该只定义字段 1 - 6 还是应该定义所有 20 个字段。另一件事是，如果我定义了所有 20 个字段，则 UserDAOImpl 类中的 SQL 将始终需要获取所有 20 个字段才能启动 userTO 对象，这会是一个问题吗？
非常感谢任何建议。谢谢！
I've got a question on the transfer object in DAO pattern. Let's say you have a USER table, and there are 20 fields in this table. In the business logic, I notice that I may need field 1 to field 3 in some scenarios, and field 4 - field 6 in other scenarios. So when I implement the userTO class, should I only define field 1 - 6 only or I should define all 20 fields. Another thing is if I define all 20 fields, the SQL in the UserDAOImpl class will always need to fetch all 20 fields in order to initiate the userTO object, will that be a issue?
Any suggestions are greatly appreciated. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
假设您的 userTO 类具有高度内聚性...
当您创建对象实例时，您始终希望确保它们是在有效状态下创建的。也就是说，您可以获取给定对象的实例，并将其传递到程序中任何位置的方法中，而不会收到编程错误类型异常（例如 NullPointerException）。这将得出这样的结论：您应该始终使用所有 20 个字段创建 userTO。
然而，我们的生活和工作却受到限制。如果在 userTO 的每个实例中填充所有 20 个字段会对您的系统造成不必要的不利压力，那么您可能需要考虑创建一个 userTOShort，其中包含经常使用的 userTO 字段的子集。然后，可以在必要时填充很少需要的“可选额外”字段。这个“短”解决方案感觉有点脏，但我不知道有更干净的解决方案。
Assuming your userTO class is highly cohesive...
When you create instances of objects you always want to ensure that they are created in a valid state. That is, that you can take an instance of a given object and be able to pass it into a method anywhere in your program without receiving programming error type exceptions (e.g. NullPointerException). This would lead to conclusion that you should always create your userTO with all 20 fields.
However, we live and work within contraints. If having all 20 fields populated in each instance of userTO causes unnecessary and adverse strain on your system then you might want to think about perhaps creating a userTOShort, which contains a subset of userTO fields that are used frequently. Then the "optional extra" fields that are needed very rarely can be populated when necessary. This "short" solution feels a bit dirty but I don't know of a cleaner solution.