3

我是具有 (Windows) 系统管理员背景的 C# 编码器。我一直在研究各种服务框架，以便为各种基础设施组件（Windows 管理、硬件管理等）创建统一的 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？

抱歉，如果我在这里滥用任何术语...

4

2 回答 2

2

有了各种各样的后端服务和数据源，我认为很难使用像框架这样高度结构化的东西来将数据映射到 DTO。我会保持简单：

将 DTO 类与任何后端类分开。通常抵制尝试在 DTO 中重用代码、使用继承等的诱惑（尽管有时我发现声明接口以供 DTO 实现很有用）。这将使您的 ServiceStack 服务的界面保持干净并且独立于后端细节。

ServiceStack 中有一些扩展方法可以轻松地在两个类之间映射属性：TranslateTo、PopulateWith、PopulateWithNonDefaultValues等。上面的链接提到了这些。诀窍是，虽然您的 DTO 类不应该是后端类的子类或直接重用后端类，但如果您想使用这些映射方法，您会发现匹配属性名称很方便。

保持你的 ServiceStack 服务类简单；他们的主要职责应该是在 DTO 类和较低级别的模型类之间进行转换，并对业务逻辑类进行一两个方法调用来完成实际工作。

听起来这对于您的业务层的最高级别（您的 ServiceStack 服务与之交互的类）很有用，以提供一个干净的接口，该接口抽象出有关给定类型数据的源和格式的详细信息。所以你可能需要三层模型类。从上到下：DTO、业务层 POCO 类和特定后端服务的特定框架类，例如 Web 参考生成的代码或其他。

我想这就是它的全部。

于 2013-08-22T15:33:18.440 回答
0

我建议您定义满足 API 要求的 DTO，然后在实际对象和 DTO 之间建立一个“业务逻辑”层。

您的 ServiceStack 服务将依赖于 DTO 定义和业务逻辑层，而业务逻辑层将依赖于 DTO 定义和真实世界的对象定义。实际上，您的 REST 服务和 DTO 将充当真实世界 API 的外观。

于 2013-08-22T15:40:35.947 回答