值得在 DTO 中使用 getter 和 setter 吗？ (C++)
我必须编写一堆 DTO（数据传输对象）——它们的唯一目的是在客户端应用程序和服务器应用程序之间传输数据，因此它们有一堆属性、一个序列化函数和一个反序列化函数。
当我看到 DTO 时，它们通常有 getter 和 setter，但是它们对于这些类型的类有什么意义吗？我确实想知道我是否曾经在方法中进行验证或进行计算，但我想可能不会，因为这似乎超出了他们的目的范围。
在服务器端，业务层处理逻辑，而在客户端，DTO 仅用于视图模型（并将数据发送到服务器）。
假设我对这一切的处理都是正确的，人们会怎么想？
谢谢！
编辑：如果是这样，将 get / set 实现放入类定义中是否会出现任何问题？保存重复 cpp 文件中的所有内容...
I have to write a bunch of DTOs (Data Transfer Objects) - their sole purpose is to transfer data between client app(s) and the server app, so they have a bunch of properties, a serialize function and a deserialize function.
When I've seen DTOs they often have getters and setters, but is their any point for these types of class? I did wonder if I'd ever put validation or do calculations in the methods, but I'm thinking probably not as that seems to go beyond the scope of their purpose.
At the server end, the business layer deals with logic, and in the client the DTOs will just be used in view models (and to send data to the server).
Assuming I'm going about all of this correctly, what do people think?
Thanks!
EDIT: AND if so, would their be any issue with putting the get / set implementation in the class definition? Saves repeating everything in the cpp file...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您有一个类，其明确目的只是将其成员变量存储在一个位置，那么您也可以将它们全部公开。
If you have a class whose explicit purpose is just to store it's member variables in one place, you may as well just make them all public.
该对象可能不需要析构函数（如果您需要清理资源，例如指针，则只需要析构函数，但如果您要序列化指针，则只是自找麻烦）。拥有一些语法糖构造函数可能很好，但没有什么真正必要的。
如果数据只是用于携带数据的普通旧数据 (POD) 对象，那么它是结构体（完全公共类）的候选者。
但是，根据您的设计，您可能需要考虑添加一些行为，例如 .action() 方法，该方法知道如何将其携带的数据集成到实际的 Model 对象中；而不是让实际模型本身集成这些更改。实际上，DTO 可以被视为控制器（输入）的一部分，而不是模型（数据）的一部分。
无论如何，在任何语言中，getter/setter 都是封装不良的标志。每个实例字段都有一个 getter/setter 不是 OOP。 对象应该是丰富的，而不是贫乏的。如果你真的想要一个贫血对象，那么跳过 getter/setter 并直接进入 POD 完全公共结构；与完全公共结构相比，使用 getter/setter 几乎没有任何好处，除了它使代码复杂化，因此如果您的工作场所使用代码行数作为生产力指标，它可能会给您更高的评级。
The object would likely not require destructor (you only need a destructor if you need to cleanup resources, e.g. pointers, but if you're serializing a pointer, you're just asking for trouble). It's probably nice to have some syntax sugars constructors, but nothing really necessary.
If the data is just a Plain Old Data (POD) object for carrying data, then it's a candidate for being a struct (fully public class).
However, depending on your design, you might want to consider adding some behavior, e.g. an .action() method, that knows how to integrate the data it is carrying to your actual Model object; as opposed to having the actual Model integrating those changes itself. In effect, the DTO can be considered part of the Controller (input) instead of part of Model (data).
In any case, in any language, a getter/setter is a sign of poor encapsulation. It is not OOP to have a getter/setter for each instance fields. Objects should be Rich, not Anemic. If you really want an Anemic Object, then skip the getter/setter and go directly to POD full-public struct; there is almost no benefit of using getter/setter over fully public struct, except that it complicates code so it might give you a higher rating if your workplace uses lines of code as a productivity metric.