我喜欢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();
}
}
}
在数据上下文中,我的对象的属性autogenerated 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数据类和混淆,这可以揭示更正确的架构?
您使用哪种混淆工具有助于支持此过程?
回顾你从尝试中学到的东西,你能否建议你是否会再次尝试相同的过程?你会尝试另一种方式。
我的偏好当然是让所有东西都完全混淆,如果它给我提供很少的保护,就不会坚持使用半开烘烤的高包装。
答案 0 :(得分:5)
“我的偏好当然是让所有东西都完全混淆,如果它给我提供很少的保护,就不会坚持使用半开的包装和高昂的开销。”
您确定需要在解决方案的这个方面进行模糊处理吗?你实际上在尝试'保护'是什么?
根据我的经验,好处来自于混淆自定义UI代码和业务逻辑类。 (竞争对手可以复制和利用)。
混淆自动生成的服务代码没有太大的好处。你在那里确实没有多少IP来保护...
您正在使用的工具应该允许您定义要混淆的类和不混淆的类。我不会将这种方法描述为“半烘焙”