LinqToSql 混淆

Question

我喜欢 LinqToSql 数据上下文对象和底层 SQL 数据库之间的紧密耦合，但我很好奇混淆是如何融入图片的。

[global::System.Data.Linq.Mapping.ColumnAttribute(Storage="_FamilyId", IsPrimaryKey=true, IsDbGenerated=true)]
public int FamilyId
{
  get
  {
    return this._FamilyId;
  }
  set
  {
     if ((this._FamilyId != value))
     {
        this.OnFamilyIdChanging(value);
        this.SendPropertyChanging();
        this._FamilyId = value;
        this.SendPropertyChanged("FamilyId");
        this.OnFamilyIdChanged();
     }
  }
}

在数据上下文中，在这种情况下，我的对象的属性自动生成的设置器对 PropertyName 进行了硬编码，例如。 SendPropertyChanging 方法调用中的“FamilyId”字符串。下次重新生成文件时将替换此代码中的更改，因此我无法使用反射助手获取属性名称。

很明显，一旦发生混淆，这个属性将被称为完全不同的东西。这似乎可以防止通知事件到达 WPF 应用程序 UI 事件处理程序。

所以我想，让我们尝试将这些自动生成的数据对象包装起来，适配器模式样式。至少包装器会被混淆。所以按照stackoverflow hardcode vs reflection

    private Family _family;

    public int FamilyId
    {
        get { return _family.FamilyId; }
        set
        {
            NotifyPropertyChanging(() => FamilyId);
            _family.FamilyId= value;
            NotifyPropertyChanged(() => FamilyId);
        }
    }

在我尝试处理集合之前，这似乎还可以。 EntitySet 集合更复杂，因为集合中的每个元素都需要转换为 wrap 类型。此外，当我们开始谈论延迟加载、事务以及我们不是在真实类型上执行业务层逻辑而是包装类型的事实时，复杂性开始增加。

所以我的直觉是，这变得越来越复杂。

是否还有其他人使用 WPF、LinqToSql 数据类和混淆技术来阐明更正确的架构？

您正在使用哪种混淆工具来帮助支持此过程？

回顾您从尝试中学到的东西，您能否建议您是否会再次经历相同的过程？你会尝试另一种方式吗？

我的偏好当然是完全混淆所有内容，而不是坚持使用半生不熟的高开销包装，如果它给我的保护很少。

Answer 1

“我当然更喜欢完全混淆所有内容，而不是坚持半生不熟的高开销包装，如果它给我的保护很少。”

您确定需要在解决方案的这方面进行混淆处理吗？你到底想“保护”什么？

根据我的经验，它的好处来自于混淆自定义 UI 代码和业务逻辑类。 （竞争对手可能会复制和利用）。

混淆自动生成的服务代码并没有太多好处。你真的没有太多的知识产权可以保护......

您使用的工具应该允许您定义要混淆的类和不混淆的类。我不会将这种方法描述为“半生不熟”