13

我想知道通过 WCF 服务公开哪些对象有意义 - 我应该将 WCF 序列化规范添加到我的业务实体，还是应该实现一个转换器，将我的业务实体映射到我想通过我的 WCF 公开的 DataContracts服务？

现在我有不同级别的实体：DataAccess、Business 和 Contract。我有转换器可以将实体从 DataAccess 映射到 Business，从 Business 映射到 Contract，反之亦然。实施和维护这些非常耗时且非常乏味。与此相关的最佳实践是什么？

如果我使用的是诸如 NHibernate 或实体框架之类的 OR/M，我应该直接从 ORM 中公开实体，还是应该像现在一样抽象它们？

4

4 回答 4

12

一般来说，我认为从最佳实践的角度来看，您不应该将业务对象的结构公开为数据合约，而是定义“特定于数据合约的”类并将业务转换为合约。它可能需要额外的工作，但从关注点分离和保护变化的角度来看，额外的工作可能是值得的。

Microsoft 模式和实践“服务工厂建模版”实现了这一点，还提供了自动生成业务 <=> 合同转换器类的工具——它是一个出色的 VS 插件，也代表了 Microsoft 的 WCF 最佳实践。

于 2008-09-17T14:27:20.177 回答
4

我通常不会通过网络公开我的业务/数据实体，因为我喜欢遵守单一责任原则 (srp)。为了解释，创建数据实体以映射到底层关系 (db) 模型。所以他们应该“改变”的唯一原因是关系模型的改变，就是这样。

当您暴露这些实体以便它们可以越线时，它们有两个目的。这可能看起来有点矫枉过正，但它让事情变得更清洁和透明......这会产生更简单的设计。

于 2008-09-17T14:27:26.650 回答
1

还需要考虑的一点是，我同意这种分离，但它通常会导致“翻译器”或一些这样的代码将数据从 DTO 复制到业务实体。这就是像 AutoMapper ( http://automapper.org/ ) 这样的库真正派上用场的地方，并且不需要编写翻译层。

于 2012-08-13T17:05:16.310 回答
1

只是添加到上述答案：Web 服务公开的对象称为数据传输对象 (DTO)。拥有一个 DTO 来映射您的业务实体对象 (BEO) 是很好的，因为它在您的 Web 服务和 Web 服务背后的实际实现/逻辑之间提供了分离。

最后，这里介绍了如何装饰 DTO，以便当它被 WSDL 公开时，名称反映了它所代表的实际对象（而不是 objectNameDTO 或类似的丑陋的东西）。

//Business Entity
class Person
{
   public string Name{ get; set; }
   public int Age{ get; set; }
}


//Data transfer object
[DataContract(Name="Person")] //<-- this is what makes the WSDL look nice and clean
class PersonDTO
{
   [DataMember(Name = "Name", Order = 0)]
   public string Name{ get; set; }
   [DataMember(Name = "Age", Order = 1)]
   public int Age{ get; set; }
}
于 2010-03-08T16:47:58.030 回答