designfrage - session und objekte

22/05/2008 - 16:10 von Holger Kreissl | Report spam
Hallo,

ich habe eine grundlegende Frage. Momentan leite ich alle webpages von
einer eigenen Basisklasse ab, welche Elemente bereitstellt oder
Schnittstellen bereitstellt, die von allen Seiten genutzt werden sollen.

Nun benutze ich einige ausgelagerte Module (Assemblies) wie verschiedene
DAL's oder einfacher einen XML Konfigwrapper.

Nun möchte ich natürlich von überall aus auf diese Objekte zugreifen
können. Den XML Konfigwrapper konnte ich als Singleton Klasse
implementieren, weshalb der Aufruf statisch ist. Das ist also
unproblematisch.

Was aber mit Objekten die instanziiert werden müssen, um zum Beispiel
dem Konstruktor einen ConnectionString oder Daten aus des aktuellen
Nutzers zu übergeben.

Zur Zeit speichere ich diese Objekte in einer Property der BasisPage,
welche das Objekt wiederrum aus einer Sessionvariable holt, bzw das
Objekt erzeugt, wenn es noch nicht existiert.

Public ReadOnly Property MySettings() As DBSettingsData
Get
If Session("SettingsData") Is Nothing Then
Session("SettingsData") = New DBSettingsData
End If

Return Session("SettingsData")
End Get
End Property

Somit hat jeder Nutzer sein eigenes Objekt. In der Masterpage ist dann
eine Delegation auf diese Eigenschaft denkbar.

Nun die eigentliche Frage. Ist der Weg o.k. oder gibt es elegantere
Möglichkeiten. Gibt es ein Pattern für ASP.NET wie man solche Objekte
verwendet, bzw. wo man sie hinterlegt? Eventuell direkt als Extension?
Oder gibt es evtl. eine Art Guideline die verschiedenes klàrt - Wann
speichert man das Objekt in der Session, oder in Application, wann
sollte man es immer neu erzeugen und wieviel Daten sollte man maximal in
eine Sessionvariable ablegen, bevor Performanceeinbußen zu befürchten sind?

Über ein paar links oder hinweise würde ich mich sehr freuen.


Grüße

Holger Kreissl
.NET Software Developer
http://kreissl.blogspot.com/
 

Lesen sie die antworten

#1 Peter Bucher [MVP]
22/05/2008 - 17:34 | Warnen spam
Hoi Holger

Nun möchte ich natürlich von überall aus auf diese Objekte zugreifen
können. Den XML Konfigwrapper konnte ich als Singleton Klasse
implementieren, weshalb der Aufruf statisch ist. Das ist also
unproblematisch.


Ein Singleton bringt IMHO nicht wirklich viel, bzw. ist hier nicht nötig.
Eine statische Eigenschaft, die das Objekt instanziiert und bspw. in
HttpContext.Current
ablegt, tut die Sache.

Nach einem Request ist der Krempel eh wieder hin :-)

Was aber mit Objekten die instanziiert werden müssen, um zum Beispiel dem
Konstruktor einen ConnectionString oder Daten aus des aktuellen Nutzers zu
übergeben.


s.o.

Zur Zeit speichere ich diese Objekte in einer Property der BasisPage,
welche das Objekt wiederrum aus einer Sessionvariable holt, bzw das Objekt
erzeugt, wenn es noch nicht existiert.
[...]
Somit hat jeder Nutzer sein eigenes Objekt. In der Masterpage ist dann
eine Delegation auf diese Eigenschaft denkbar.

Nun die eigentliche Frage. Ist der Weg o.k. oder gibt es elegantere
Möglichkeiten. Gibt es ein Pattern für ASP.NET wie man solche Objekte
verwendet, bzw. wo man sie hinterlegt? Eventuell direkt als Extension?
Oder gibt es evtl. eine Art Guideline die verschiedenes klàrt - Wann
speichert man das Objekt in der Session, oder in Application, wann sollte
man es immer neu erzeugen und wieviel Daten sollte man maximal in eine
Sessionvariable ablegen, bevor Performanceeinbußen zu befürchten sind?

Über ein paar links oder hinweise würde ich mich sehr freuen.


Was wo gespeichert wird, sollte primàr bzw. alleine vom benötigten Kontext
bestimmt werden.

D.h.

Benutzer -> Session
Anwendung -> Application
Request -> HttpContext.Items
...

In Sessions sollte so wenig wie möglich gespeichert werden.
Ich halte es so, das ich - wenn möglich - nur IDs oà. speichere,
aufgrund dessen können die Infos dann von einer externen Ressource geholt
werden.

Der Grund ist einfach:
Session Inhalte werden solange gehalten, bis das Timeout vorbei ist, oder
aber die Session manuell gekillt wird.
Wenn jetzt bspw. ein Benutzer zwei, dreimal auf die Seite geht (Und sie in
der Zwischenzeit schliesst ohne sich abzumelden),
sind es schon die Daten * 3. Das noch mal 1000 Benutzer gerechnet, ergibt
bei entsprechenden Daten viel Speicher
der vorhanden sein muss.

Der Engpass ist dann meistens auch die Speichergrenze für einen Application
Pool, und nicht unbedingt
die RAM-Kapazitàt des Servers.

Zu HttpContext.Items guck mal hier:
-
http://www.aspnetzone.de/blogs/pete...rrent.aspx
-
http://www.aspnetzone.de/blogs/juer...ieren.aspx

Gruss, Peter Bucher
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland
http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community
http://www.aspnetzone.de/blogs/peterbucher/ - Auf den Spuren von .NET

Ähnliche fragen