我是一名具有 (Windows) 系统管理员背景的 C# 程序员。我一直在研究各种服务框架，以便为各种基础结构组件(Windows 管理、硬件管理等)创建统一的 REST-API。我已经决定使用 ServiceStack 作为我的框架，但对如何管理我的 DTO 有疑问。大多数时候，我的源数据来自非数据库对象，其中包括:
- 其他网络服务(通常基于 SOAP)。我通常通过“添加 Web 引用”引入这些(大多数，但不是全部，都是 asmx)。
- .NET 对象(通常是 WMI/WinRM/PowerShell [System.Management]，或 Active Directory [System.DirectoryServices])...
- 在某些不幸的情况下，我会因为调用命令(通过 ssh 或 cmd)而获得原始文本输出。
在所有这些情况下，我都必须调用某种 Save() 方法来更新属性。此外，我可能还想向 REST 服务公开一些非 CRUD 方法。通常我不需要源数据中的所有内容(例如，在 Web 服务数据的情况下，我只对封装特定代理类的某些属性和方法感兴趣)。我的理解是我的 DTO 应该是干净的并且没有任何依赖关系。由于我不相信我有可以使用的 ORM，我应该使用什么设计模式来将我的数据映射到 DTO？
如果我在这里误用了任何术语，我深表歉意...
最佳答案
有了各种各样的后端服务和数据源，我认为很难使用像框架这样的高度结构化的东西来将数据映射到 DTO。我会保持简单:
Keep your DTO classes separate来自您的任何后端类。通常抵制尝试在 DTO 中重用代码、使用继承等的诱惑(尽管有时我发现为 DTO 实现声明接口(interface)很有用)。这将使您的 ServiceStack 服务的界面保持干净并且独立于后端细节。
ServiceStack 中有一些扩展方法可以轻松地在两个类之间映射属性:TranslateTo、PopulateWith、PopulateWithNonDefaultValues 等。链接上面提到了这些。诀窍在于，虽然您的 DTO 类不应是后端类的子类或直接重用后端类，但如果您想使用这些映射方法，您会发现让属性名称匹配很方便。
让您的 ServiceStack 服务类保持简单；他们的主要职责应该是在 DTO 类和较低级别的模型类之间进行转换，并对业务逻辑类进行一两个方法调用以完成实际工作。
这听起来对您的业务层的最高级别——您的 ServiceStack 服务与之交互的类——提供一个干净的接口(interface)很有用，该接口(interface)抽象出有关给定类型的源和格式的详细信息数据。所以你可能想要三层模型类。从上到下:DTO、业务层 POCO 类，以及用于特定后端服务(例如 Web 引用生成的代码等)的特定于框架的类。
我认为这就是它的全部内容。
关于c# - ServiceStack 和非数据库对象，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18384457/