[.NET] State in ASP.NET bewaren adhv Reflection en Attribute

[whoami]

In de december 2002 uitgave van dr. Dobbs, ben ik net op een interessant artikel gebotst getiteld:
ASP.NET Page Persistence & Extended Attributes.
Daarin doet de auteur (David Hovel, ex-'Microsoftee' [member of the WinNT group]) een techniek uit de doeken die hem helpt om op een makkelijke manier z'n aspx pagina's state te laten bewaren. Hij doet dit mbhv attributen en reflection.
Hij maakt een attribuut aan dat dan gebruikt wordt in z'n webpages om aan te geven of de inhoud van een bepaald veld moet bewaard worden of niet.
Dat attribuut ziet er als volgt uit:

code:

public enum PagePersistEnum { eSession, eApplication, eWebConfig};

[AttributeUsage(AttributeTargets.Fields)]
public class PagePersistAttribute : System.Attribute
{
  protected PagePersistEnum ePersist;

  public PagePersistAttribute(PagePersistEnum ePersist)
  {
    this.ePersist = ePersist;
  }

  public PagePersistEnum PersistLevel
  {
    get 
    {
      return ePersist;
    }
  }
}

Met behulp van die enumerator kan er dus aangegeven worden waar de inhoud moet bewaard worden, in de sessie, applicatie of in de web.config.
In je webpages ga je dus mbhv dit attribuut gaan aangeven welke 'fields' er moeten gepersist worden, en waar ze moeten gepersist worden.
Verder heeft de auteur dan nog een class geschreven die een Save en Restore method bevat. Die methods gaan mbhv reflectie na welke velden er hun state moeten bewaren (welke hebben er dus het PagePersist attribute) en gaat deze dan ook op de juiste plaats gaan bewaren (of op de juiste plaats gaan ophalen).
Nu, dit lijkt me wel een heel handige en makkelijke manier om zo state te gaan bewaren. Ik heb er zelf nog niet met ge-experimenteerd, maar ik ga dat zeker eens doen. Ik wou jullie het concept gewoon niet onthouden en postte dit hier dan maar even (zeer beknopt natuurlijk, wil je meer info, dan moet je maar eens het betreffende artikel opsporen. Het staat misschien ook online [niet nagechecked]).

[Verwijderd]

Ik heb het artikel hier ook liggen.
Ziet er interessant uit.
Er is een voorbeeldproject te downloaden bij Dr. Dobbs http://www.ddj.com/ftp/2002/2002_12/persistdemo.zip
Ik heb er wat mee geexperimenteerd, maar heb niet het idee dat de Application string onderaan de pagina bewaard wordt.

[whoami]

Zijn er misschien mensen die nog een andere techniek hebben om state op een redelijk generieke manier te bewaren, of zijn er mensen die reeds eens met bovenstaand voorbeeld aan de slag geweest zijn? Zoja, wat zijn de bevindingen?

[JohanDM]

Heel mooi ogende methode: heel generiek, snel gecodeerd, etc.
Maar performant kan je dit niet noemen, goed voor demo's en zo...

Ik heb er deze bedenking bij: naargelang je klasse/pagina complexer wordt, groeit het aantal overbodige checks die uitgevoerd worden.
Simpel voorbeeld: je hebt een pagina met 5 members waar je er 3 van wil bewaren, de slimme klasse voor save en restore gaat dan de 5 members af en kijkt met reflection na of er een actie moet ondernomen worden, op zich een nog te verwerken performance hit: slechts 40% onnodig werk (2 die niet moesten gesaved/restored worden) + een sterke omweg via reflection om aan de waarde van de members te geraken die wel moeten gesaved/restored worden.
Maar dit wordt al snel erger, vb: 20 members waarvan er 4 moeten bijgehouden worden, dat geeft al 80% onnodig werk.

Het attribuut-idee op zich vind ik niet verkeerd, maar ik zie meer heil in gegenereerde code zodat maar eenmalige de volledige structuur moet afgezocht worden, waarna er een nieuwe assembly gecompileerd kan worden die heel performant de state kan saven en restoren, door rechtsreeeks enkel de members te nemen die moeten gesaved worden en dan ineens naar de juiste locatie.

Je kan zeggen dat "performance er niet toe doet", maar dat is hetzelfde als zeggen dat "schaalbaarheid er niet toe doet" en ja als je "maar 5 gebruikers hebt en een 4-way Opteron server met 16GB RAM" dan hoef je inderdaad niets van performance aan te trekken.

[Verwijderd]

JohanDM schreef op 03 februari 2003 @ 18:19:
Je kan zeggen dat "performance er niet toe doet", maar dat is hetzelfde als zeggen dat "schaalbaarheid er niet toe doet" en ja als je "maar 5 gebruikers hebt en een 4-way Opteron server met 16GB RAM" dan hoef je inderdaad niets van performance aan te trekken.

Ok, performance doet er uiteraard toe, maar zolang dit snel genoeg werkt, tja waar zou je je dan druk om maken? Ik denk dat >90% van de pagina's die geschreven worden niet bepaald voor veel load op een webserver zullen zorgen, verder kun je natuurlijk altijd net die paar pagina's waar 95% van de bezoekers rond hangt even met de hand optimaliseren...

Met jou redenatie kan je trouwens heel dat attributen en reflectie verhaal direct in de prullebak mikken, aangezien het altijd ten koste van performance zal gaan.

[ Voor 4% gewijzigd door Verwijderd op 03-02-2003 19:14 ]