我喜欢 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();
}
}
}
在数据上下文中，在这种情况下，我的对象的属性自动生成的 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 数据类和混淆来阐明更正确的架构？
您使用哪种混淆工具来帮助支持此过程？
回顾您从尝试中学到的东西，您能否建议您是否会再次经历同样的过程？你会尝试另一种方式吗。
我的偏好当然是完全混淆所有内容，而不是坚持使用高开销的半生不熟的包装，如果它给我的保护很少的话。
最佳答案
“我的偏好当然是完全混淆所有内容，如果它给我的保护很少，则不要坚持使用高开销的半生不熟的包装。”
您确定您的解决方案的这个区域需要混淆吗？您实际上想“保护”什么？
根据我的经验，好处来自混淆自定义 UI 代码和业务逻辑类。 (竞争对手可能会复制和利用)。
混淆自动生成的服务代码并没有太大的好处。您实际上没有多少 IP 可以保护...
您使用的工具应该允许您定义要混淆的类和不混淆的类。我不会将这种方法描述为“半生不熟”
关于c# - LinqToSql 混淆，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4281597/