vb .net extend property

[DutchKel]

Mijn vraag
Ik heb een stukje code wat ik eigenlijk niet mag aanpassen (dit ivm een gegenereerde klasse)

code:

    <System.Xml.Serialization.XmlElementAttribute>
    Public Property Initials() As String
        Get
            Return Me.initialsField
        End Get
        Set
            Me.initialsField = Value
        End Set
    End Property

Van zulke properties zijn er een stuk of 250, de klasse wordt gegenereerd aan de hand van een XSD welke regelmatig wordt uitgebreid.

Nu moet ik een controle doen of de Get methode is toegestaan. Dit is een simpele controle en zou er ongeveer zo uit kunnen zien in de code:

code:

    <System.Xml.Serialization.XmlElementAttribute>
    Public Property Initials() As String
        Get
            If (IsAllowed("Initials")) Then
                Return Me.initialsField
            Else
                Throw New Exception("It is not allowed to use this property")
            End If
        End Get
        Set
            Me.initialsField = Value
        End Set
    End Property

Deze check dient dus voor elke property te gebeuren in de desbetreffende klasse. Echter kan ik de klasse zelf niet gaan aanpassen omdat deze vaak opnieuw wordt gegenereerd vanuit de XSD.

Ik zat zelf de denken aan een base klasse, maar daarmee loop ik ook vast omdat de properties dan alsnog aangepast moeten worden voor zover mijn kennis gaat.

Heeft iemand een idee hoe ik de check kan doen zonder de property zelf aan te passen?

Relevante software en hardware die ik gebruik
Visual Studio 2017
.Net Framework 2.0 (vanwege legacy redenen is een hogere .net versie niet mogelijk)
VB .Net
Windows 10 Professional

Wat ik al gevonden of geprobeerd heb
Op google gezocht naar "vb .net always execute code on property" en "vb .net extend property" maar uit de resultaten komt alleen maar dat het niet mogelijk is.

[NickThissen]

Hoe wordt deze code gegenereerd? Kun je dat niet aanpassen?

[Killah_Priest]

Getters kun je toch gewoon dmv reflection controleren?

[DutchKel]

NickThissen schreef op donderdag 5 april 2018 @ 16:48:
Hoe wordt deze code gegenereerd? Kun je dat niet aanpassen?

De code wordt gegenereerd dmv Xsd.exe welke wordt meegeleverd met de microsoft .net installatie, deze is dus helaas niet aan te passen.

Killah_Priest schreef op donderdag 5 april 2018 @ 16:50:
Getters kun je toch gewoon dmv reflection controleren?

Heb je hier een voorbeeld van hoe ik dit kan toepassen op de gegeven property? Ik heb me net even een beetje verdiept in reflection maar ik zie helaas niet in hoe dit me gaat helpen, buiten dat ik daarmee wel de property binnen de check makkelijk kan opvragen.

[CodeIT]

Een optie is om een inherited klasse te maken en daar de properties te overloaden. Dat is wel aardig wat typewerk.

Visual Basic .NET:

Public Class MyTest
    Inherits Test

     Public Overloads Property Initials() As String
        Get
            If (IsAllowed("Initials")) Then
                Return MyBase.Initials
            Else
                Throw New Exception("It is not allowed to use this property")
            End If
        End Get
        Set
            MyBase.Initials = Value
        End Set
    End Property
End Class

Een alternatief kan reflection zijn. Bijvoorbeeld met Fody

Overigens kun je de naam van de property in VB.Net krijgen met de NameOf operator. Je krijgt dan If IsAllowed(NameOf(Initials)) zodat je code strongly typed is.

[DutchKel]

CodeIT schreef op donderdag 5 april 2018 @ 17:07:
Een optie is om een inherited klasse te maken en daar de properties te overloaden. Dat is wel aardig wat typewerk.

Visual Basic .NET:

Public Class MyTest
    Inherits Test

     Public Overloads Property Initials() As String
        Get
            If (IsAllowed("Initials")) Then
                Return MyBase.Initials
            Else
                Throw New Exception("It is not allowed to use this property")
            End If
        End Get
        Set
            MyBase.Initials = Value
        End Set
    End Property
End Class

Een alternatief kan reflection zijn. Bijvoorbeeld met Fody

Overigens kun je de naam van de property in VB.Net krijgen met de NameOf operator. Je krijgt dan If IsAllowed(NameOf(Initials)) zodat je code strongly typed is.

Bedankt, ik ga morgen Fody eens bekijken en jou code eens uitgebreid bekijken. Ik denk dat ik daar wel mee verder kom.

[Lethalis]

Waar is de controle voor?

Want ik vind het eerlijk gezegd een vreemde methode om toegang af te schermen.

Logischer vind ik dat als Pietje de Initials property niet mag gebruiken, hij enkel met een klasse kan werken die de properties bevat die hij mag gebruiken.

Deze kunnen jouw gegenereerde klasse eventueel wrappen of nog beter door een adapter apart gevuld worden.

Bijkomend voordeel is dat de rest van de code niet meer afhankelijk is van een klasse die regelmatig verandert.

[ Voor 13% gewijzigd door Lethalis op 05-04-2018 20:20 ]

[DutchKel]

Lethalis schreef op donderdag 5 april 2018 @ 20:18:
Waar is de controle voor?

Want ik vind het eerlijk gezegd een vreemde methode om toegang af te schermen.

Logischer vind ik dat als Pietje de Initials property niet mag gebruiken, hij enkel met een klasse kan werken die de properties bevat die hij mag gebruiken.

Deze kunnen jouw gegenereerde klasse eventueel wrappen of nog beter door een adapter apart gevuld worden.

Bijkomend voordeel is dat de rest van de code niet meer afhankelijk is van een klasse die regelmatig verandert.

Ik zal het even in details uitleggen. We hebben een xsd welke de canonicaldata bevat, hier staan alle properties in welke we gebruiken om informatie te transporteren via xml tussen verschillende systemen. Hierbij valt te denken aan personeelsgegevens, projectgegevens etc.

In totaal is de xsd intussen ongeveer 160KB groot en staan er ontzettend veel properties in welke gebruikt worden voor het transport systeem. Deze xsd zorgt ervoor na het omzetten naar vb .net dat we de xml's welke worden getransporteerd in onze projecten als object kunnen benaderen. Dit ipv elke keer de xml's parsen met alle fouten van dien.

Nu wordt de wet aangepast mbt de persoonsgegevens, dus hebben we encryptie en signing toegepast op de xml's. Dit werkt allemaal prima, echter als een applicatie geen toegang heeft tot de encrypted gegevens krijgt die op het moment een lege waarde en in onze applicaties wordt een lege waarde in de eindapplicaties gezet als lege waarde. De eindapplicatie heeft er geen weet van dat de property eventueel is encrypted en dus eventueel wel gevuld kan zijn.

De check zorgt er dus voor dat ALS er encryptie op het bericht is toegepast en het bericht kan door de instellingen niet gedecrypt worden en er wordt net een property opgevraagd die binnen de encryptie valt dat er dan een exception wordt opgegooid zodat de applicatie omvalt. Er zijn verschillende redenen te bedenken wanneer dit optreed o.a.:
-Verkeerde instellingen
-De applicatie mag de prive gegevens niet hebben maar het is toch geprogrammeerd (misschien door een externe partij oid)

Aangezien we een stuk of 60-70 interfaces hebben draaien welke allemaal deze canonicaldata gebruiken is het dus makkelijker om het bij de canonicaldata te regelen ipv alle interfaces een voor een te gaan doorgronden en kijken of die niet per ongeluk ongedocumenteerd private properties gebruiken.

Juist omdat we zoveel interfaces hebben en de xml structuur beheersbaar moet zijn hebben we alle xsd data inclusief het parsen ervan in 1 nuget project gestopt welke regelmatig bijgewerkt wordt. We hebben het in het verleden andersom gedaan bij een aantal projecten, echter lopen deze nu telkens vast als de xml veranderd terwijl de nuget package updaten niks stuk maakt aan de werking van de applicatie (immers komen er normaal alleen properties bij).

Maar om even terug te komen op jou opmerking, het is dus niet bedoeld om toegang af te schermen, daar hebben we de encryptie voor bedacht, alleen om te checken of je wel werkelijk toegang hebt.

Ik hoop dat het nu een beetje duidelijk is.

[sig69]

Misschien een idee: met xsd.exe fields ipv properties genereren, en daarna met een t4 template of iets dergelijks de properties genereren.

[DutchKel]

Ik heb nog een alternatief gevonden: https://github.com/codaxy/xsd2

Dit project ga ik aanpassen zodat de properties direct op de gewenste manier worden gegenereerd.

[vandeGerrit]

Als ik even de design guides erbij pak: Property design en Exception Design wordt het afgeraden moet je voorkomen dat getters exceptions kunnen gooien.

Property getters should be simple operations and should not have any preconditions. If a getter can throw an exception, it should probably be redesigned to be a method. Notice that this rule does not apply to indexers, where we do expect exceptions as a result of validating the arguments.

Daarnaast is het wenselijk om voor de persoon welke werkt met deze klassen alvorens hij een GET uitvoert, ook zelf nog kan controleren of dit wel is toegestaan.
Aangezien je het hebt over de methode: IsAllowed neem ik aan dat een deze eerst wordt aangeroepen alvorens de get. In theorie weet het systeem dan al of hij dan een eventuele null waarde kan negeren, je roept deze methode immers aan in de property. De exception hoeft dan ook niet en volstaat een null teruggeven. Op de plek waar je wilt weten of de waarde 'zinnig' is kan je de IsAllowed aanroepen alvorens je de get doet.

[DutchKel]

vandeGerrit schreef op vrijdag 6 april 2018 @ 21:50:
Als ik even de design guides erbij pak: Property design en Exception Design wordt het afgeraden moet je voorkomen dat getters exceptions kunnen gooien.

Property getters should be simple operations and should not have any preconditions. If a getter can throw an exception, it should probably be redesigned to be a method. Notice that this rule does not apply to indexers, where we do expect exceptions as a result of validating the arguments.

Daarnaast is het wenselijk om voor de persoon welke werkt met deze klassen alvorens hij een GET uitvoert, ook zelf nog kan controleren of dit wel is toegestaan.
Aangezien je het hebt over de methode: IsAllowed neem ik aan dat een deze eerst wordt aangeroepen alvorens de get. In theorie weet het systeem dan al of hij dan een eventuele null waarde kan negeren, je roept deze methode immers aan in de property. De exception hoeft dan ook niet en volstaat een null teruggeven. Op de plek waar je wilt weten of de waarde 'zinnig' is kan je de IsAllowed aanroepen alvorens je de get doet.

Dit is bekend, echter is het niet houdbaar om 60-70 (als het er niet meer zijn) interfaces aan te passen, ook omdat ze niet allemaal intern zijn ontwikkeld. Lees mijn uitgebreide aanvulling er eens op na, daar staan meer details in over het waarom.

Dus helaas is er geen betere oplossing voorlopig dan dit uitvoeren.

Echter ben ik vandaag al erg ver gevorderd om het xsd2 project naar mijn wens aan te passen.

[Lethalis]

DutchKel schreef op vrijdag 6 april 2018 @ 21:58:
[...]

Dit is bekend, echter is het niet houdbaar om 60-70 (als het er niet meer zijn) interfaces aan te passen, ook omdat ze niet allemaal intern zijn ontwikkeld. Lees mijn uitgebreide aanvulling er eens op na, daar staan meer details in over het waarom.

Dus helaas is er geen betere oplossing voorlopig dan dit uitvoeren.

Echter ben ik vandaag al erg ver gevorderd om het xsd2 project naar mijn wens aan te passen.

Ik begrijp dat je graag 1 package met een API wil maken die iedereen voortaan gebruikt. Zo kun je inderdaad voorkomen dat er rare dingen gebeuren op allerlei plekken.

60 tot 70 interfaces klinkt veel, anderzijds kan ik mij niet voorstellen dat ze allemaal zo vaak veranderen. Meestal zie je dat van die 70 interfaces er misschien 10 vaak veranderen (omdat externe partijen ze vaak wijzigen), maar dat de rest nooit meer verandert.

Toch?

En dan is het antwoord op de vraag of het "niet houdbaar is" wellicht anders.

Mijn indruk is dus dat je voor de snelle en makkelijke oplossing gaat

Sowieso ben ik benieuwd hoe je dit project test. Het is immers centraal voor alles. Want zodra je hier unit tests voor gaat schrijven zul je toch ook per interface dingen moeten schrijven en aanpassen.

Kruipt er ergens een bugje in jouw aangepaste code generator dan kan dat erg vervelend uitpakken.

Been there done that. En jij bent dan degene die er verantwoordelijk voor is...

Goed ontworpen interfaces veranderen niet vaak, ze worden alleen uitgebreid en blijven zoveel mogelijk compatibel met oudere versies.