[servlets] gedeelde objecten

[Verwijderd]

Ik ben sindskort bezig met servlets ter vervanging van php scripts. Simpele 'standalone' servlets heb ik nu ervaring mee en dit gaat goed, maar nu wil ik een wat uitgebreider systeem gaan bouwen, waarbij ik uiteindelijk de volgende opzet wil bereiken:

- een 'bekijk' servlet: data tonen, sorten etc. Data halen uit cache
- een 'bewerk' servlet: data opslaan, cache bijwerken
- het cache object

Hoe maak ik van het cache object een gedeeld object? (als dat een juiste omschrijving is) De bedoeling is dat beide servlets er gebruik van maken. Het bekijken zal namelijk veel vaker gebeuren dan bewerken, voor performance wil ik geen queries voor het bekijken gebruiken.

[stp_4]

bedoel je het maken van de klasse cache?

[Verwijderd]

ja, hoe zorg ik er voor dat er 1 instantie van de klasse cache is die beide servlets kunnen gebruiken?

[Verwijderd]

Mijn eerste gedachte zou zijn om van deze cache een Singleton te maken. Hoewel ik van mening ben dat je deze niet te pas en te onpas moet gebruiken, denk ik dat dit hier wel uitkomst kan bieden.

[Alarmnummer]

Verwijderd schreef op maandag 22 november 2004 @ 12:53:
Mijn eerste gedachte zou zijn om van deze cache een Singleton te maken. Hoewel ik van mening ben dat je deze niet te pas en te onpas moet gebruiken, denk ik dat dit hier wel uitkomst kan bieden.

Singletons zijn erguh naar. Je hebt er namelijk geen controle over en daarom zijn systemen met singletons ook een stuk lastiger te testen. En verder kan je in sommige omgevingen geen singletons gebruiken, bv bij ejb.

Ik zou persoonlijk zeggen: neem een container die je tussen de servlets kan sharen. Uit die container kunnen de servlets dan hun info halen. Spring heeft bv zo`n container. Als je het idee erachter snapt.. dan wil je nooit meer zonder.

[Verwijderd]

Volkomen waar, maar als antwoord op deze vraag lijkt mij dat nogal een paardenmiddel, met een kanon op een mug schieten, proberen een Mercedes te verkopen aan iemand die op zoek is naar een Fiat en meer van dat soort analogieën...

[ Voor 20% gewijzigd door Verwijderd op 22-11-2004 13:37 ]

[Verwijderd]

Ik heb inmiddels al een stukje gevonden over attributes, die je in alle servlets in dezelfde context kunt gebruikten.

Daarnaast vraag ik me intussen af waarom zou ik niet gewoon 1 servlet maken die alle pagina's kan afhandelen. Iedere pagina moet toch uit templates opgebouwd worden. Dus ik kan ook gewoon een servlet maken met een stukje code wat adhv url de juiste functies uit voert (uit verschillende klassen)

[Verwijderd]

Inderdaad, de ServletContext. In jsp's is dat de 'application' variable.

[Verwijderd]

Verwijderd schreef op maandag 22 november 2004 @ 14:14:
Daarnaast vraag ik me intussen af waarom zou ik niet gewoon 1 servlet maken die alle pagina's kan afhandelen.

Dat kun je overwegen. Houd echter wel goed in de gaten dat 1 servlet klasse niet per definitie leidt tot 1 instantie van die klasse. Kijk even goed of de servlet steeds opnieuw geinstantieerd wordt, of per sessie, of daadwerkelijk slechts 1 keer. Is waarschijnlijk ergens in deployment te regelen.

[Alarmnummer]

Verwijderd schreef op maandag 22 november 2004 @ 13:34:
Volkomen waar, maar als antwoord op deze vraag lijkt mij dat nogal een paardenmiddel, met een kanon op een mug schieten, proberen een Mercedes te verkopen aan iemand die op zoek is naar een Fiat en meer van dat soort analogieën...

Ik ben het gedeeltelijk wel met je eens.. Maar ik zit dus met een applicatie en een hele rits singletons en probeer die zo goed en kwaad als het kan allemaal te verwijderen. Testen is ronduit een nachtmerrie. Dus Singleton is een mogelijk oplossing... maar met de opmerking erbij dat het wel een rotte oplossing is.

[TukkerTweaker]

Alarmnummer schreef op maandag 22 november 2004 @ 14:38:
[...]

Ik ben het gedeeltelijk wel met je eens.. Maar ik zit dus met een applicatie en een hele rits singletons en probeer die zo goed en kwaad als het kan allemaal te verwijderen. Testen is ronduit een nachtmerrie. Dus Singleton is een mogelijk oplossing... maar met de opmerking erbij dat het wel een rotte oplossing is.

Dat ligt nogal aan de manier waarop je de singletons gebuikt imo. Een singleton om data te cachen die voor ALLE gebruikers van die servlet nodig is, is niks mis mee. Waarom dat niet te testen is mag je me dan uitleggen. Een singleton is imo prima geschikt bijvoorbeeld om server side processen uit te voeren uit met een que.
Voor gebruiker gerelateerde data zou ik inderdaad een session object aanroepen en daar attributen instoppen, uithalen.

[Alarmnummer]

TukkerTweaker schreef op maandag 22 november 2004 @ 14:54:
[...]
Dat ligt nogal aan de manier waarop je de singletons gebuikt imo. Een singleton om data te cachen die voor ALLE gebruikers van die servlet nodig is, is niks mis mee. Waarom dat niet te testen is mag je me dan uitleggen.

Omdat je geen controle hebt binnen een bepaald object welke andere objecten gebruikt worden. Als er ineens een singleton wordt gebruikt kan jij daar niet even eenvoudig een stub tussen plakken.

Een singleton is imo prima geschikt bijvoorbeeld om server side processen uit te voeren uit met een que.

Ben ik het dus 110% mee oneens.

Als jou object een queue nodig heeft, kan hij deze referentie via de klassieke manier mee krijgen. Via een constructor of eventueel via een setter (heb ik persoonlijk een hekel aan). Deze situatie is in 9 van de 10 gevallen wenselijk doordat je nu ook veel eenvoudiger tegen een interface aan kunt programmeren ipv tegen een vaststaande implementatie.

Ik ben dus de afgelopen tijd veel met Spring bezig en daarbij zijn me zoveel dingen duidelijk geworden.. nouja duidelijk.. zoals ik wil programmeren onder j2ee is met Spring nu mogelijk. Een IOC zorgt er voor dat er een minimale dependency tussen objecten mogelijk is. Dit is niet alleen handig om te testen, maar ook om het gedrag van het systeem aan te passen: je krijgt gewoon een flexibeler en duidelijker te testen systeem.

Ik wil daarmee niet zeggen dat Singletons volslagen nutteloos zijn. Maar op de een of andere manier heeft iedereen enorm veel problemen onder j2ee om aan referenties naar objecten te komen. En dat is volslagen bullshit en een enorm gebrek aan j2ee. Vandaar dat een goeie container de aanvulling is die j2ee gewoon domweg mist.

Picocontainer/Nanocontainer zijn ook prachtige oplossingen.

[edit flamemode ]
Ik vind dat j2ee niet het ontwerp moet bepalen, maar dat jij dat zelf moet kunnen doen. Het moet een hulpmiddel zijn en niet een dwangbuis. Daarom ben ik dus ook helemaal tegen bv ejb in zijn huidige vorm.

[ Voor 27% gewijzigd door Alarmnummer op 22-11-2004 15:45 ]

[Verwijderd]

Als je client side code ziet, waarin instantiatie van meerdere singletons met elkaar is verweven (en om het nog erger te maken GUI code, exception gevoelige code en liefst ook mulit-threading erin vermengd), dan ga je begrijpen wat Alarmnummer bedoelt met moeilijk testen. Vraag blijft of dit nu de schuld is van de singleton of van de ontwikkelaar die er onnodig, verkeerd en slordig gebruik van maakt.

Singletons hebben meer nadelen, als het gaat om overerving, flexibiliteit - mocht ineens blijken dat je toch 2 of meer instanties nodig hebt omdat je 2 servers gaat draaien, en leesbaarheid.

[TukkerTweaker]

Alarmnummer schreef op maandag 22 november 2004 @ 15:11:
[...]

Omdat je geen controle hebt binnen een bepaald object welke andere objecten gebruikt worden. Als er ineens een singleton wordt gebruikt kan jij daar niet even eenvoudig een stub tussen plakken.


[...]

Ben ik het dus 110% mee oneens.

Als jou object een queue nodig heeft, kan hij deze referentie via de klassieke manier mee krijgen. Via een constructor of eventueel via een setter (heb ik persoonlijk een hekel aan). Deze situatie is in 9 van de 10 gevallen wenselijk doordat je nu ook veel eenvoudiger tegen een interface aan kunt programmeren ipv tegen een vaststaande implementatie.

Ik ben dus de afgelopen tijd veel met Spring bezig en daarbij zijn me zoveel dingen duidelijk geworden.. nouja duidelijk.. zoals ik wil programmeren is met Spring nu mogelijk. Een IOC zorgt er voor dat er een minimale dependency tussen objecten mogelijk is. Dit is niet alleen handig om te testen, maar ook om het gedrag van het systeem aan te passen: je krijgt gewoon een flexibeler en duidelijker te testen systeem.

Ik wil daarmee niet zeggen dat Singletons volslagen nutteloos zijn. Maar op de een of andere manier heeft iedereen enorm veel problemen onder j2ee om aan referenties naar objecten te komen. En dat is volslagen bullshit en een enorm gebrek aan j2ee. Vandaar dat een goeie container de aanvulling is die j2ee gewoon domweg mist.

Picocontainer/Nanocontainer zijn ook prachtige oplossingen.

[edit flamemode ]
Ik vind dat j2ee niet het ontwerp moet bepalen, maar dat jij dat zelf moet kunnen doen. Het moet een hulpmiddel zijn en niet een dwangbuis. Daarom ben ik dus ook helemaal tegen bv ejb in zijn huidige vorm.

Klopt, voor een langlopend project is deze het gebruik van het Spring framework zeker aan te bevelen. Maar om dat te gebruiken voor 1 of 2 functies die gemakkelijk met een singleton op te lossen zijn, daar zou ik die test en enheretance problemen maar voor lief nemen.
Een goede container API is inderdaad een aanvulling op j2ee.

[Alarmnummer]

TukkerTweaker schreef op maandag 22 november 2004 @ 15:46:
[...]
Klopt, voor een langlopend project is deze het gebruik van het Spring framework zeker aan te bevelen.

Is niet ieder project langlopend?

Maar om dat te gebruiken voor 1 of 2 functies die gemakkelijk met een singleton op te lossen zijn, daar zou ik die test en enheretance problemen maar voor lief nemen.
Een goede container API is inderdaad een aanvulling op j2ee.

Het probleem aan deze instelling is dat je zo snel ermee op je bek gaat. Ohh.. ff dit erin raggen.. ff dat erin prakken.. en dan is je systeem in eens niet meer onderhoudbaar.

Verder creeer je dan ook een bepaalde toon die gezet gaat worden binnen een project. Check The Pragmatic Programmer: From Journeyman to Master eens. Er staat een heel leuk stuk in : "Broken window"

[edit]
http://c2.com/cgi/wiki?FixBrokenWindows

[ Voor 23% gewijzigd door Alarmnummer op 22-11-2004 16:15 ]

[TukkerTweaker]

Alarmnummer schreef op maandag 22 november 2004 @ 16:00:
[...]

Is niet ieder project langlopend?

Gelukkig niet. Voor de meeste projecten is er een functioneel ontwerp en afhankelijk van de scope hoeft deze niet aan verandering onderheving te zijn. Hierdoor kan iets heel goed kortlopend zijn, bijvoorbeeld het 1 malig generen van PDF's uit een x antal XML bestanden.

[...]

Het probleem aan deze instelling is dat je zo snel ermee op je bek gaat. Ohh.. ff dit erin raggen.. ff dat erin prakken.. en dan is je systeem in eens niet meer onderhoudbaar.

Verder creeer je dan ook een bepaalde toon die gezet gaat worden binnen een project. Check The Pragmatic Programmer: From Journeyman to Master eens. Er staat een heel leuk stuk in : "Broken window"

[edit]
http://c2.com/cgi/wiki?FixBrokenWindows

Voor sommige oplossing is het niet verkeerd om pragmatisch te werk te gaan om de kosten en tijdinspanning binnen de perken te houden, zie mijn eerdere voorbeeld. Maar dit gaat wel erg off-topic.