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

回答

相關問題