LinqToSql Obfuscation

Question

Ich mag die enge Kopplung zwischen LinqToSql Daten Kontextobjekte und der zugrunde liegenden SQL-Datenbank, aber ich bin gespannt, wie Verschleierung in das Bild passt.

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

Im Daten Zusammenhang die Eigenschaft automatisch generierte Setter für meine Objekte in diesem Fall schwer Codes der Property zB. "FamilyId" Zeichenfolge in dem SendPropertyChanging-Methodenaufruf. Änderungen in diesem Code werden beim nächsten Neugenerieren der Datei ersetzt, daher kann ich Reflection-Helfer nicht verwenden, um die Eigenschaftsnamen abzurufen.

Offensichtlich sobald Verschleierung aufgetreten ist, wird diese Eigenschaft etwas völlig anderes nennen. Dies scheint zu verhindern, dass das Benachrichtigungsereignis UI-Eventhandler der WPF-Anwendungen erreicht.

Also dachte ich, lassen Sie uns versuchen, diese automatisch generierten Datenobjekte nach oben, Adapter-Muster-Stil zu wickeln. Zumindest die Wrapper werden verschleiert. So wie pro stackoverflow hardcode vs reflection

private Family _family; 

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

Welche Ordnung scheint, bis ich versuche, mit Sammlungen beschäftigen. EntitySet-Auflistungen sind komplexer, da jedes Element in der Auflistung in den Wraptyp umgewandelt werden muss. Darüber hinaus beginnt die Komplexität zu wachsen, wenn wir anfangen, Lazy Loading, Transaktionen und die Tatsache, dass wir die Business-Layer-Logik nicht auf realen Typen ausführen, sondern Wraptypen, zu sprechen.

Also mein Bauchgefühl ist, dass dies zu komplex wird.

Verwendet noch jemand WPF, LinqToSql Datenklassen und Verschleierung, die etwas Licht auf eine korrekte Architektur werfen können?

Welches Verschleierungstool verwenden Sie, um diesen Prozess zu unterstützen?

Wenn Sie zurückblicken auf das, was Sie bei Ihren Versuchen gelernt haben, können Sie mir empfehlen, ob Sie denselben Prozess noch einmal durchlaufen würden? Würdest du einen anderen Weg versuchen?

Meine Vorliebe ist natürlich, alles komplett verschleiert zu haben, nicht bei halbgebackener Verpackung mit hohen Gemeinkosten zu bleiben, wenn es mir sehr wenig Schutz gibt.

Answer 1

"Meine Präferenz ist natürlich, alles komplett verschleiert zu haben, nicht mit halbgebackener Verpackung mit hohen Gemeinkosten zu bleiben, wenn es mir sehr wenig Schutz gibt."

Sind Sie sicher, dass Sie in diesem Bereich Ihrer Lösung eine Verschleierung benötigen? Was versuchst du eigentlich zu "schützen"?

Nach meiner Erfahrung kommt der Vorteil aus der Verschleierung von benutzerdefinierten UI-Code und Business-Logik-Klassen. (, dass ein Konkurrent könnte möglicherweise kopieren und Hebel).

Es gibt keinen großen Vorteil bei der Verschleierung von automatisch generiertem Service-Code. Sie haben nicht wirklich viel IP dort, um zu schützen ...

Das Werkzeug, das Sie verwenden, sollte Ihnen erlauben zu definieren, welche Klassen Sie verschleiern möchten und welche Sie nicht tun. Ich würde diesen Ansatz nicht als "halb gebacken" beschreiben