WCF 中的动态数据协定
在客户端和 WCF 服务之间传输实体存在一些痛点。
- 通过序列化所有属性来击败延迟加载
- 序列化数据可能会不必要地臃肿
- UI和业务层之间存在一些耦合
解决这些问题的一种方法是传输DTO而不是实体，但我知道这种技术有其自己的一组警告（最大的一个）我知道维护这些特定于功能的 DTO 所需的输入）。
我认为如果服务实现能够动态生成这些 DTO 并且 这似乎是可能的。不幸的是，看起来合约在客户端（即“对象”）的定义是松散的，这听起来像是一个可能的风险。
是否建议以这种方式使用动态 DTO，或者是否有另一种方法可以使用 DTO 而无需为每个 DTO 创建/维护类？
我认为圣杯是实现动态生成 DTO，但客户看到定义明确的合同。我猜这对于 WCF 来说是不可能的。
There are some pain points around transmitting entities between a client and a WCF service.
- Defeating lazy loading by serializing all properties
- Serialized data can be unecessarily bloated
- Some coupling between UI and business layer
One way to address these issues is to transmit DTOs instead of entities but I am aware that this technique has its own set of caveats (the biggest one I am aware of is the typing required to maintain these function-specific DTOs).
I think it would be great if the service implementation could generate these DTOs dynamically and this appears to be possible. Unfortunately, it looks like the contract would be loosely defined on the client side (i.e. "object") and that smells like a possible risk.
Is it advisable to use dynamic DTOs in this fashion or is there another way to use DTOs without creating/maintaining classes for each one?
I think the holy grail would be where the implementation dynamically generates DTOs but the client sees well-defined contracts. I'm guessing this isn't possible with WCF.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想问题是你要用什么来生成它们？您必须在某处对要传输的数据进行一些描述。如果您拥有的只是域对象，那么您最终会处于与通过域对象传输数据类似的位置。
DTO 实现的关键功能之一是解耦，这样您就可以发展域对象，而不会意外破坏服务的使用者。如果动态生成 DTO，那么您将级联更改 - 除非您将动态创建视为开始使用 DTO 的一次性练习
I guess the issue is what are you going to generate them from? You have to have some description somewhere of what the data you want to transmit looks like. If all you have is the domain objects then you end up in a similar position of transmitting the data that you would of via the domain object.
One of the key things the DTO enables is decoupling so you can evolve your domain objects without breaking the consumers of your service accidently. If you dynamically generate the DTOs then you will cascade the changes - unless you view the dynamic creation as a one-off exercise to get you started with a DTO
DTO 与任何其他数据契约一样，都是数据契约，必须进行定义。当您选择使用 DTO 时，您就增加了一层必须维护的复杂性。有一些工具可以帮助您在域对象和 DTO 之间进行映射（例如 AutoMapper），但您的责任是定义 DTO 应传输的内容 - 这是很难自动完成的事情。即使使用自动化工具，您仍然需要维护一些将用于生成代码的 DTO 定义。
DTO is data contract as any other and must be defined. When you choose to go with DTOs you are adding a layer of complexity which you have to maintain. There are tools which can help you with mapping between domain objects and DTOs (like AutoMapper) but your responsibility is to define what DTO should transfer - that is something which can hardly be done automatically. Even with automated tool you will still have to maintain some definition of DTOs which will be used to generate code.