POCO 与 DTO：可以部分水合域对象吗？
通常需要在 UI 上以各种方式显示域对象； 列表、搜索结果、查看和编辑页面以及页眉、页脚和弹出窗口。 通常，域对象有多个不同的“视图”，每个视图都显示不同的字段。
大多数建议似乎是在需要子集或超集时使用 DTO 来获取数据。 维护 DTO 会产生大量开销。 简单地填充每个场景所需的域对象的属性是不是一个坏方法？ 例如，您可以使用配置文件来说明应包含哪些属性，例如：
service.GetDomainObjects(int listID, Profile.ListProfile); service.GetDomainObjects(string searchParam, Profile.SearchProfile);
Its often a requirement to have a domain object displayed in various ways on the UI; lists, search results, view and edit pages, as well as in headers, footers and popups. Typically you have several different "views" of the domain object, each with different fields displayed.
Most advice seems to be to use a DTO to get the data when you require a subset or superset. There is a lot of overhead in maintaining DTOs. Is it a bad approach to simply fill the properties of the domain object required for each scenario. For instance you might use a profile to say what properties should be included, eg:
service.GetDomainObjects(int listID, Profile.ListProfile);
service.GetDomainObjects(string searchParam, Profile.SearchProfile);
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对我来说，这归结为您想要的开销，要么您将有一组不同的类来表示您的 DTO，要么您将有一组方法，每个方法都返回相同的域对象，但是不同的领域都被“水合”了。
为了帮助做出决定，我会问几个问题：
我个人对 DTO 有一点偏爱，因为我觉得系统的长期维护会更容易。 如果您是一个单人乐队，或者这是一个一次性的应用程序，我完全可以理解不想引入一堆额外的类来扰乱您的代码。
For me what this comes down to is where you want the overhead to be, either you are going to have a set of different classes to represent your DTOs, or you are going to have a set of methods that each return the same domain object but with different fields being 'hydrated'.
A couple of questions I'd ask to help make the decision are:
I have a slight personal preference for DTOs as I feel the long term maintainance of your system will be easier. If your a one man band, or this is a one off throw away app, I can totally understand not wanting to introduce a bunch of extra classes that will clutter your code.