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