我是具有(Windows)sysadmin背景的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?

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

最佳答案

对于各种后端服务和数据源,我认为很难使用任何高度结构化的东西(例如框架)将数据映射到DTO。我会保持简单:

您的任何后端类中的Keep your DTO classes separate。通常抵制尝试在您的DTO中重用代码,使用继承等的诱惑(尽管有时我发现声明接口供DTO实施很有用)。这将使您的ServiceStack服务的界面保持整洁,并且与后端详细信息无关。

ServiceStack中提供了一些扩展方法,可以轻松在两个类之间映射属性:TranslateToPopulateWithPopulateWithNonDefaultValues等。上面的链接提到了这些。诀窍在于,虽然DTO类不应该是后端类的子类,也不应该直接重用后端类,但如果要使用这些映射方法,则可以方便地将属性名称匹配起来。

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

听起来这对于您的业务层的最高层(与ServiceStack服务进行交互的类)很有用,以提供一个干净的接口,该接口抽象出有关给定类型数据的源和格式的详细信息。因此,您可能需要三层模型类。从上到下:DTO,业务层POCO类以及用于特定后端服务(例如Web参考生成的代码)之类的特定于框架的类。

我认为这就是全部。

10-05 22:31
查看更多