VB.NET singletons, globals,timers,events

[vorlox]

Beste Allemaal,

Waarschijnlijk ga ik domme vragen stellen, maar ik kan hier nou niks over vinden wat voor mij duidelijk is.

Ik ben nog niet heel lang bezig met VB.NET en op wat kleine apps na heb ik er niet heel veel ervaring mee. Ik heb wel een hoop gelezen dus daarmee ben ik aan de slag gegaan.

Nu loop ik tegen een aantqal punten aan..die meer ontwerp technisch zijn zeg maar.

Stel je hebt een klasse waarmee je verbinding maakt met een SQL server. Is het dan beter om een module te gebruiken en deze klasse 1 keer aan te roepen en global te defineren of van deze klasse een singleton maken en deze in elke klasse als privete te declareren en maar 1 keer een instance te hebben draaien? (Het nadeel is wel meteen dat je maar 1 instance kan hebben van deze klasse)

Dan vraag 2 ..timers
Ik heb in de SQL klasse een timer zitten die elke seconden een connection.ping doet om te kijken of deze nog actief is... zo niet dan geeft de klasse een ondisconnected event af..
Nu vraag ik me af wat de impact is van zo'n timer....nu is het er 1 maar als ik dit grapje meer toepas kan je misschien wel 10 timers in een applicatie hebben..

Ik hoop dat je mijn vraag begrijpt. Wat is nu een goed ontwerp om dit op te zetten.
Alvast bedankt voor het meedenken

[Verwijderd]

Jikes .... jij wilt persee een open connection hebben met de database, maar dit zou ik alleen doen als ik een HELE GOEDE REDEN had om dat te doen.

Als jouw applicatie schaalbaar moet zijn zou ik dat juist vermijden. Probeer je connectie zo kort mogelijk open te houden, want als iedere client een connectie open houdt, loopt het gebruik van server resources minimaal linieair op. Misschien niet helemaal het antwoord waar je naar op zoek was, maar wel een relevante tip.

[vorlox]

MrX
Ok bedankt... hmm. ik snap jou argument perfect hoor... maar het ligt inderdaad aan de schaalbaarheid.. het is overigens wel een goede opmerking... dus je stelt eigenlijk voor om per query de connection te openen en te closen? Ik zal daar eens mee testen.. kijken wat de performance van je app doet en je server.
Overigens was het inderdaad mijn vraag niet... als voorbeeld neem ik hier een sql klasse.. waar het me vooral om gaat is de manier van programmeren... dus zelfs al zou hij dus per query een connection openen en closen ....moet ik die SQL klasse nu als singleton of global in een module declareren?

[whoami]

vorlox schreef op vrijdag 19 augustus 2005 @ 14:13:
MrX
Ok bedankt... hmm. ik snap jou argument perfect hoor... maar het ligt inderdaad aan de schaalbaarheid.. het is overigens wel een goede opmerking... dus je stelt eigenlijk voor om per query de connection te openen en te closen? Ik zal daar eens mee testen.. kijken wat de performance van je app doet en je server.

Als je met meerdere gebruikers gaat werken, zal je zowiezo op deze manier moeten werken:
connectie openen als je ze nodig hebt
sluiten van zodra je ze niet meer nodig hebt.

Dit is belangrijk voor je schaalbaarheid, want connecties zijn duur, en als je iedere keer honderden connecties hebt open staan, dan gaat dat niet goed.
Door gebruik te maken van connection pooling (gaat automatisch in SQL Server, mits je dezelfde connection-string gebruikt), zal dit ook niet echt een negatieve impact hebben.

Echter; ik zie dat jij stelt om per query een aparte connectie te openen: dat is niet goed. Stel dat je 3 queries direct achter elkaar moet uitvoeren, dan ga je een connectie openen, die 3 queries uitvoeren met diezelfde connectie, en dan de connectie sluiten.

Overigens was het inderdaad mijn vraag niet... als voorbeeld neem ik hier een sql klasse.. waar het me vooral om gaat is de manier van programmeren... dus zelfs al zou hij dus per query een connection openen en closen ....moet ik die SQL klasse nu als singleton of global in een module declareren?

Waarom zou je die class als singleton of als global willen declareren ? Waarom zou je niet iedere keer als je die nodig hebt, een nieuwe instance ervan maken ?

[Verwijderd]

Op de Patterns & Practices website van MSDN staan een heleboel interessante verhalen over hoe je dingen het slimst kunt aanpakken. Hier is bijvoorbeeld een leuk artikel: http://msdn.microsoft.com...nagingdatabaseconnections

Connection Usage Patterns
Irrespective of the .NET data provider you use, you must always:
- Open a database connection as late as possible.
- Use the connection for as short a period as possible.
- Close the connection as soon as possible. The connection is not returned to the pool until it is closed through either the Close or Dispose method. You should also close a connection even if you detect that it has entered the broken state. This ensures that it is returned to the pool and marked as invalid. The object pooler periodically scans the pool, looking for objects that have been marked as invalid.

To guarantee that the connection is closed before a method returns, consider one of the approaches illustrated in the two code samples that follow. The first uses a finally block. The second uses a C# using statement, which ensures that an object's Dispose method is called.

Mbt die singleton vs global moet ik je het antwoord schuldig blijven.

[vorlox]

Ok duidelijk dus eigenlijk stel je voor om dus de connectie/en disconnectie te verleggen naar de code waar je ook je query aanroept.

Waarom zou je die class als singleton of als global willen declareren ? Waarom zou je niet iedere keer als je die nodig hebt, een nieuwe instance ervan maken ?

Omdat ...denk ik er anders misschien wel 10 instances draaien van een klasse...en waarom als je er maar 1 nodig hebt. Natuurlijk zal de GC ze wel opruimen maar toch..
Daarnaast is er naar mijn mening ook nog zoiets als overzichtelijk code..(dit is altijd persoonsafhankelijk heb ik gemerkt maar ok)

Even klein voorbeelde ter illustratie.
Dit vind ik een voordeel aan een singleton

code:

Public Class MyClassName

'Dims
private withevents sql as mynamespace.sql = mynamespace.sql.getInstance

private function DoIets(strQuery as string) as boolean
    sql.connect
    sql.doquery
    sql.disconnect
end function

'Event for query error enz

End Class

en dit als je ze iedere keer declared

code:

Public Class MyClassName

private function DoIets(strQuery as string) as boolean
    Dim sql as new mynamespace.sql
    addhanlder sql.onqueryerror,addressof queryerroreventhandler
    sql.connect
    sql.doquery
    sql.disconnect
end function

'Event for query error enz

End Class

En nu vraag ik me dus af wat nu eigenlijk beter is en waar ik me druk over maak hehehe

[vorlox]

Verwijderd schreef op vrijdag 19 augustus 2005 @ 14:29:
Op de Patterns & Practices website van MSDN staan een heleboel interessante verhalen over hoe je dingen het slimst kunt aanpakken. Hier is bijvoorbeeld een leuk artikel: http://msdn.microsoft.com...nagingdatabaseconnections

[...]

Mbt die singleton vs global moet ik je het antwoord schuldig blijven.

Fun, thanks

[whoami]

Eigenlijk misbruik je dus een singleton; het is in dit geval toch niet nodig dat je max. één instantie van die class hebt ?
Je zou het enkel zo doen, omdat het voor jou dan makkelijker werkt (net als je een global zou gebruiken dus).

Als je iedere keer je connectie sluit, dan heb je geen honderden objecten rondslingeren.

[vorlox]

whoami schreef op vrijdag 19 augustus 2005 @ 14:42:
Eigenlijk misbruik je dus een singleton; het is in dit geval toch niet nodig dat je max. één instantie van die class hebt ?
Je zou het enkel zo doen, omdat het voor jou dan makkelijker werkt (net als je een global zou gebruiken dus).

Als je iedere keer je connectie sluit, dan heb je geen honderden objecten rondslingeren.

Ojee dit snap ik weer niet.. waarom misbruik ik nu een singleton... ik wil 1 instance hebben en met een singleton heb ik er altijd 1.. dus is precies wat het moet doen. plus je kunt het ook gebruiken om via classen te communiceren.. dus als er een critical event gegenereed wordt kan ik dat al vanuit de sql instance doorgeven aan alle andere klassen die ook een ref. naar de SQL instance hebben..

of denk ik nu echt helemaal verkeerd en zoja ... kun je misschien een klein voorbeeldje hiervan geven.. Het gaat dus niet om werkende code maar op de manier van opzet zegmaar.

Als je iedere keer je connectie sluit, dan heb je geen honderden objecten rondslingeren

Niet helemaal.. want dit heeft weer te maken met die SQL connection. En daar gaat het hier niet om..het was een voorbeeld.. en inderdaad lezend uit het stuk wat MrX me aangaf is het het beste om zo snel mogelijk de db connection weer te closen... ok so it will be done..
Het zou dan ook niet zo zijn dat ik honderden connection object had openstaan maar meer honderden klasse met daarin het SQL object... en wat ik al zij weet ik helemaal niet wat de impact is.. en ik zie er dus geen voordeel aan boven het gebruik van een singleton in dit geval.
Maar nu zit ik dus nog om de manier van code opzet in een willekeurige applicatie.. Soms wil je een soort engine hebben die maar 1 keer een instance nodig heeft maar welk communiceert met alle andere klassen... ik vindt zelf een singleton dan een geweldige oplossing..

[ Voor 33% gewijzigd door vorlox op 19-08-2005 15:07 ]