修剪 WCF 服务中反序列化的空间答案

【问题标题】：Trimming Spaces on Deserialization in WCF Services修剪 WCF 服务中反序列化的空间
【发布时间】：2014-10-09 08:45:56
【问题描述】：

我的要求是采用一种通用方法来确保数据库中没有存储前导/尾随空格。我们的架构是 WCF->业务逻辑管理器->通用存储库->Entity Framework 5.0 -> DB

现在我有两种方法可以做到这一点

在 Generic Repository 中执行（但在这里我必须在整个对象图中搜索字符串属性并更改值）
在 WCF 管道中反序列化时执行此操作（但在这里我可能必须放置我的自定义序列化程序，我不想这样做，因为我想要的只是序列化期间的一个事件，我可以在其中查询属性类型和改变它的价值）

我赞成方法 2，但要寻找最简单的方法来做到这一点，而无需更改整个序列化程序。有没有一种方法可以在不使用自定义序列化程序的情况下进行更改。我们目前正在使用 XmlSerializer。

寻找以下输入(2)

哪种方法性能更好
如何将我的小方法附加到 WCF 管道中现有的序列化过程中。

谢谢，视频

【问题讨论】：

“我的要求是采用一种通用方式来确保数据库中不存储前导/尾随空格”您的要求是什么级别？是交通要求吗？
是持久化需求，消息已经到达最后一层，现在需要持久化。我想在 XML 被反序列化时解决这个问题，这样我就不必再次使用反射来查询类型及其值。
这是一个反问。我知道我的问题的答案。我的观点是“最小意外原则”。至于你对反思的关注。您的 ORM 已经拥有实体类型的元数据（它知道所有属性，以及其中哪些是字符串）。实现需求的代码离它来自的实际层越远……你拥有的“惊喜”越多，一些中间代码就越有可能为你捏造它。
我猜你是对的，如果任何开发人员不小心更改了任何下游层中的数据，事情可能会走下坡路。再三考虑，我意识到 ParameterInpectors 可以用于这样的任务，但我将不得不再次回到反射，因为我将挖掘字符串类型的整个对象图。存储库是做这种事情的最佳场所。谢谢，我很高兴标记这个答案:)。

标签： wcf deserialization pipeline

【解决方案1】：

您的代码应该在数据层而不是序列化层上运行，因为那是需求的来源。

至于实施，您有两种选择。

您可以使用 DbChangeTracker 或 IDbCommandInterceptor（EF6 中的新功能）来更改 EF 上下文的行为。

以下是如何使用更改跟踪器轻松做到这一点

public class FooContext : DbContext
{
    public override int SaveChanges()
    {
        var items = ChangeTracker.Entries().Where(e => e.State == EntityState.Added).ToList();
        foreach(var item in items)
        foreach(var property in item.PropertyNames)
        {
            var propValue = item[property] as string;
            if(propValue != null)
            {
                item[property] = propValue.Trim();
            }
        }
        return base.SaveChanges();
    }
}

【讨论】：