DTO
我正在构建一个希望扩展到许多用户的 Web 应用程序。此外,我需要通过 Web 服务向受信任的第三方公开功能。
我正在使用 LLBLGen 生成数据访问层(使用 SQL Server 2008)。目标是构建一个业务逻辑层,使 Web App 免受 DAL 细节的影响,当然,还提供 DAL 之外的额外验证级别。此外,据我现在所知,Web 服务本质上将是 BLL 的薄包装器。
当然,DAL 有自己的一组实体对象,例如 CustomerEntity、ProductEntity 等等。但是,我不希望表示层直接访问这些对象,因为它们包含特定于 DAL 的方法,并且程序集特定于 DAL 等等。因此,这个想法是创建数据传输对象 (DTO)。这个想法是,本质上,这些将是普通的旧 C#/.NET 对象,它们具有所有字段,例如 CustomerEntity,实际上是数据库表 Customer,但没有其他东西,除了一些 IsChanged/IsDirty 属性。因此,会有 CustomerDTO、ProductDTO 等。我假设这些将继承自基本 DTO 类。我相信我可以使用 LLBLGen 的一些模板生成这些,但我还不确定。
因此,这个想法是 BLL 将通过接受和返回这些 DTO 对象来公开其功能。我认为 Web 服务将处理将这些对象转换为 XML 以供使用它的第三方使用,许多可能没有使用 .NET(此外,有些东西可以通过 Web 应用程序上的 AJAX 调用使用 JSON 进行脚本调用)。
我不确定设计这个的最佳方法以及如何前进。这里有一些问题:
1)这应该如何暴露给客户端(表示层和Web服务代码)
我在想会有一个具有这些方法的公共类,每次调用都是原子操作:
InsertDTO、UpdateDTO、DeleteDTO、GetProducts、GetProductByCustomer 等等...
然后客户端只需调用这些方法并传入适当的参数,通常是 DTO。
这是一个好的、可行的方法吗?
2)从这些方法返回什么?显然,Get/Fetch 类型的方法将返回 DTO。但是插入呢?部分签名可能是:
InsertDTO(DTO dto)
但是,插入时应该返回什么?我想收到错误通知。但是,我对某些表使用自动递增主键(但是,一些表具有自然键,尤其是多对多表)。
我想到的一个选项是 Result 类:
class Result
{
public Exception Error {get; set;}
public DTO AffectedObject {get; set;}
}
因此,在插入时,DTO 将获取其获取 ID(如 CustomerDTO.CustomerID)属性集,然后放入此结果对象。如果 Result.Error != null 客户端将知道是否有错误,然后它会从 Result.AffectedObject 属性中知道 ID。
这是一个好方法吗?一个问题是,它似乎在来回传递大量冗余数据(当它只是 ID 时)。我不认为添加“int NewID”属性是干净的,因为某些插入不会有这样的自动递增键。另一个问题是我认为 Web 服务不能很好地处理这个问题?我相信他们只会在 Result 类中返回 AffectedObject 的基本 DTO,而不是派生的 DTO。我想我可以通过拥有大量不同类型的 Result 对象(可能从基本 Result 派生并继承 Error 属性)来解决这个问题,但这似乎不太干净。
好吧,我希望这不是太罗嗦,但我想清楚。