POCO、DTO 和 IDataErrorInfo
今天早上我醒来发现一个问题！
在我的所有组件中，我都有一组业务规则，用于在将任何更改提交到存储库之前验证 DTO。
我一直在尝试找出将验证错误返回到 UI 的最佳方法，并且遇到了 IDataErrorInfo 接口。极好的！
然而，该接口的实现会将我的 DTO 转换为 POCO，并使其成为内存使用量更大的对象。目前，所有用户控件都绑定到当前的 DTO 对象。
将 DTO 转换为 POCO 会对性能产生影响吗？或者是否有更好的方法将验证消息返回到 UI？
I awake this morning to a problem!
In all of my components, I have a set of Business Rules which are used to validate DTOs before any changes are committed to the repository.
I've been trying to figure out the best way to get validation errors back to the UI and I came across the IDataErrorInfo interface. Fantastic!
However, The implementation of this interface would transform my DTO into a POCO and make it a larger object in terms of memory usage. At the moment, all of the user controls are bound to the current DTO objects.
Would transforming my DTOs into POCOs have a performance impact? Or is there a better way to get validation messages back to the UI?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
MVVM。即您的 DTO 包含在视图模型中，视图模型绑定到您的视图。
MVVM. i.e. yours DTOs are wrapped in view models, which are bound to your view.
绝对地。为什么你一开始就不知道自己在做什么？ IDataErrorInfo 已完整记录 - 不是您应该“遇到”的东西（这听起来是偶然的）。
DTO 绝对没有必要了解内部错误 - 它不应该永远存在内部错误。请注意，DTO 是“数据传输对象”，而不是“业务对象”。 DTO 是业务对象应该生成以将其发送到 DataAccessLayer 的内容，不应该进行验证的原因是业务对象确保只有有效的对象才能创建 DTO。
顺便提一句。，
我还有另一个惊喜发现给你 - 你的 DTO 已经是 POCO。 POCO 是“普通旧 CLR 对象”，我猜您的 DTO 是作为 .NET 类建立的，所以 - 你猜怎么着，令人惊讶的是，它们已经是 POCO。
你的意思是（又是一个有待发现的东西）是它将你的 DTO 转换为 BO。
不，没有。向 UI 发送消息的最佳方式是通过 UI 定义的接口，IDataErrorInfo 就是这样。
您的问题是您对以下问题非常困惑：
请参阅 POCO 与 DTO 中的答案，了解您实际混淆的内容。
回到绘图板。作为您的首席开发人员/架构师，向您介绍多层架构并阅读 .NET 文档。
DTO 不应处理数据传输问题。
Absolutely. How comes you do not know what you are doing in the first place? IDataErrorInfo is fully documented - not something you should "coming across" (which sounds accidentally).
A DTO has absolutely no business knowing aboutinternal errors - it should not never ever HAVE internal errors. See, DTO is "Data Transfer Object", not "Business Object". The DTO is what the Business object should generate to send it to the DataAccessLayer, and the reason there should not be validation is taht the Business Object makes sure ONLY VALID OBJECTS CREATE DTO's.
Btw.,
I have another surprise discovery for you - your DTO already IS A POCO. POCO is "Plain Old CLR Object", and I guess the your DTO are established as .NET classes, so - guess what, surprise, they already ARE POCO.
What you mean (again something to discover) is that it would transform your DTO's into BO's.
No, there is not. The best way to send messages up to the UI is by UI defined interfaces, and IDataErrorInfo is that.
Your problem is that you have a hugh confusion about:
See the answers at POCO vs DTO for an explanation of what you actually mix up.
Back o the drawing board. As your lead developer / Architect to give you an introduction into multi tiered architectures and read the .NET documentation.
The DTO should noly deal with DataTransfer issues.