LinqToSql混淆

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

[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(); 
    } 
    } 
}

在数据上下文中，属性为我的对象自动生成setter，在这种情况下，硬编码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集合更为复杂。另外，当我们开始谈论延迟加载，事务以及我们没有在真实类型上执行业务层逻辑但事实上包装类型时，复杂性就开始增长。

所以我的直觉是，这是复杂的方法。

是否有其他人使用WPF，LinqToSql数据类和混淆，可以揭示更正确的架构？

您正在使用哪种模糊处理工具来帮助支持此过程？

回想一下你从你的尝试中学到了什么，你能推荐你是否会再次经历同样的过程？你会尝试另一种方式。

我的偏好当然是让所有的东西都完全模糊不清，如果它没有给我提供很少的保护，那么就不要用高开销的半烘烤包装。

来源

2010-11-25 Westy

“我的选择当然是要拥有的一切完全混淆，不与高开销的一半烤包裹坚持，如果它给我很少的保护”。

您确定您需要在解决方案的这个区域混淆吗？你究竟想要“保护”什么？

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

模糊自动生成的服务代码没有太多好处。你真的没有太多的IP来保护...

你正在使用的工具应该允许你定义你想要混淆的类以及哪些你不需要混淆的类。我不会将这种方法描述为“半烤”

来源

2010-11-26 00:31:21 Andrew

您提出了一个很好的观点，正如您正确地指出自动生成的代码本身的IP很少。我想它只是关于黑客可以通过使用自动生成的可读属性名称获得隐含知识的担忧。我最近试图使用实体框架来使用相同的DAL，因为可以关闭代码生成，以支持手动POCO定义。然后我可以完全混淆这些公共财产。不要插入特定的产品，但RedGate SmartAssembley是我曾经在某种程度上取得成功的产品。 – Westy 2010-11-29 03:33:28

回答

相关问题