.NET 使用实体转换器的服务负担答案

【问题标题】：.NET Service burden of using Entity Translator.NET 使用实体转换器的服务负担
【发布时间】：2010-12-19 11:33:52
【问题描述】：

在 .NET 和 WCF 应用程序中，我们需要维护 EntityTranslator 来将业务消息转换为服务消息和将服务消息转换为业务消息。事实上，我不能将它们称为业务对象，因为我们只需要从数据库中获取并更新它们。我们从设备读取数据并存储到数据库，从数据库读取数据并存储到设备。

我们所有的类都是简单、普通的 .NET 类，不做任何特定的事情。

这是非常相似的类。

这是我的服务实体。

[DataContract]
public class LogInfoServiceEntity
{
   string data1;
   string name;
}

public class  LogInfo
{
   string data1;
   string name;
}

现在我需要定义翻译器只是为了创建对方的实例类型并将数据复制到对方。我们有大约 25 个这样的课程，我们觉得管理它们非常困难。所以我们有 25 名企业到服务的翻译和 25 名服务到企业的翻译。

我喜欢使用简单的 POJO 类来存储和获取信息，而不是使用所有的翻译器。

处理这种情况的最佳方法是什么？要么翻译是处理这种情况的最佳方式吗？

【问题讨论】：

【解决方案1】：

这可能是一个愚蠢的问题，但是你为什么不呢

使用相同的类您使用的 DataContract “商业信息”？

通常您将合同分开，这样您就可以在不影响数据合同的情况下更改业务对象，但是将它们分开您有什么好处？

【讨论】：

【解决方案2】：

答案是“视情况而定”。这完全取决于您的系统的复杂性。通常 WCF 服务接口应该是粗粒度的，不一定要一对一地映射到您的业务层实体，以防止额外的往返服务器。

例如，WCF 接口中的 Customer 实体可以传达更多信息，甚至与业务层中的 Customer 实体没有直接关系。但是您还返回此信息是因为您预测在 85% 的情况下，客户不仅需要客户数据，而且在接下来的几分钟内还需要所有订单/活动或任何其他补充信息。

这是通常的权衡 - 是返回更多还是更少。

在您的特定情况下，我会坚持使用代码生成：您始终可以编写一个工具，从业务逻辑实体中生成所有外部接口和转换器。

【讨论】：

【解决方案3】：

Automapper 可能就是您要找的。p>

【讨论】：