以下是我们的架构简介：
------------- --- | UI | | | ------------- | | | Services | | D | ------------- | T | | Businsess | | O | ------------- | | | Dal | | | ------------- ---
我们知道我们应该让DTO类在服务和UI之间专门在层之间传递数据但是我们有一些关于使用DTO(发送到UI或从UI接收)的方式的概念性问题.
对于数据驱动项目,我们可以使用POCO自动生成DTO对象.但在大型应用程序中,并不是那么简单.
我们知道解决问题的两种解决方案：
第一种解决方案(除了新手动创建的DTO之外,使用POCO)
例如,假设我们有一个包含许多字段的实体.并且有一个查找组合框,显示实体记录.我们只需要一个实体键作为组合框值字段,另一个字段(例如Title)作为组合框文本字段.因此,我们创建一个名为“GetAllItemsTitle”的方法来检索所有实体.现在我们应该返回我们想要的结构(本例中的一个键和一个值).所以我们必须创建一个新类来存储该结构(一个键和一个值).
这将是新的DTO课程：
[DataContract]
public class SampleManuallyDto
{
[DataMember]
public long Id { get; set; }
[DataMember]
public string Title { get; set; }
}
方法签名是这样的：
public List<SampleManuallyDto> GetAllItemsTitle()
第二种解决方案(使用Nullable或Emptyable DTO)
我们可以绕过POCO并手动创建DTO.然后我们可以将DTO的所有属性定义为可空或类似可以被识别为空的属性(我称之为Emptyable).它允许我们将DTO用于多种目的.当然,我们需要遵循适配器模式.例如,为名为“FromEntity”和“ToEntity”的可清空DTO创建两个方法,将我们手动创建的DTO转换为EntityObjects(实体框架).
现在,我们可以在“第一个解决方案”(GetAllItemsTitle)的示例中绕过创建新的DTO类.
方法签名将如下所示：
public List<SampleDTO> GetAllItemsTitle()
但是在方法体中我们只填充SampleDTO的“Id”和“Title”属性.正如我所说,SampleDTO的所有属性都可以为空,所以我们只填充我们想要的那些并将其他属性留空.
结论
通常,第一种解决方案(除了新的手动创建的DTO之外使用POCO)是强类型的.只需查看方法签名(没有额外的属性)就可以找到每个方法的返回数据类型.但我们担心管理手动创建的DTO.他们很快就会长大.
但第二种解决方案是一种更动态的方式,识别将从“GetAllItemsTitle”返回的内容的唯一方法是查看方法体或其文档.所以我们担心“运行时错误”.开发人员可能会认为属性在空时不应为空.
更重要的是,当我们将数据从UI“转换为服务”时,我们遇到了这样的问题.例如,对于Update和Insert以及其他此类操作.即使是“搜索标准”,我们也有同样的选择.
很抱歉这个问题很长.
请帮助我们您的好意见.
如何构建DTO或如何使用它并不重要.唯一重要的是如何将它们设计为最小化每个操作的Web服务调用量.
例如：假设您有一个用例,您需要遍历所有用户以修改其地址.如果您首先需要获取所有用户,然后为每个用户进行Web服务调用以获取其地址,那么设计就会很糟糕.一个合适的设计是在一次调用中返回UserWithAddress DTO：s的列表.