我知道已经有几个关于这个问题的答案，但我只是不想从错误的角度开始。我的 POCO 具有在我的存储库中工作的继承和接口，我认为这是使用存储库模式的标准方式，对吗？因此，根据我的阅读，我应该将我的 POCO 复制到 DTO 中以便在我的服务中使用它们？真的吗？
当他们谈论使用 DTO 的开销时，这就是他们所说的吗？
我意识到“简单的客户数据库 REST 服务示例”很好......很简单，但它仍然发回了 POCO。如果客户有很多属性并且您想要创建它，那么 CreateCustomer DTO 是否必须具有与客户 POCO 相同的属性？并且当您响应 GetCustomer 时，如果 POCO 具有接口/继承，您将无法返回它。
也许我只是不明白...看起来工作量很大。
【问题讨论】：
标签： web-services servicestack poco dto
很难提供明确的答案，因为您并没有真正提出明确的问题或提供具体的例子来说明您的担忧。
听起来你想做的很多事情都是不鼓励的做法，我建议调整你对什么是有效的看法，因为你想做的捷径可能会导致你在路上遇到问题。
如果您使用像 OrmLite 这样的代码优先 POCO ORM，您可以重复使用 a lot of your Data Models as DTO's，但它们应该在 ServiceModel 项目（又名 DTO .dll）中维护。当您的内部数据模型和外部服务合同发生分歧时，您应该维护一个单独的 DTO，此时您可以使用built-in AutoMapping 在它们之间轻松转换。
除了定义您的外部服务合同（您最重要的合同）之外，您不想将您的请求 DTO 重复使用。它本质上是一个操作，理想情况下按call semantics and Response Types 分组，因为您的数据模型通常是与操作它们的操作无关的名词。
您应该考虑使用将您的请求 DTO 定义为 DSL 的 POCO 类，其中它的属性提供了明确的参考来源，明确描述了您的服务接受/返回的内容。 POCO 是声明性的，将它们隐藏在继承之后会增加间接性，模糊关注点并降低清晰度，我不认为这是节省工作。
虽然接口（或基类）属性允许代码中的松散耦合，但它们在序列化时会产生相反的效果，这需要专有的序列化扩展并耦合到 .NET 命名空间，从而降低互操作性 - 服务的核心目标之一。它们也可能在未来导致运行时错误。
【讨论】：