[java] JavaBeans & Servlets, wanneer en waarom

[TheRebell]

Hoi (poging 2 door het goed werken van posten NOT)

maargoed

Ik heb nu een tijdje bezig met JSP pages, JavaBeans en Servlets. Nu kom ik er alleen niet uit wanneer je nou voor een bean kiest en wanneer een Servlet, en waarom
In die mooie boeken hier staat het antwoord daarop ook niet echt.
Zit ik nou goed als ik zeg dat je (bv) invoercontrole en kleine stukje verwerking door beans laat doen en (bv) databaseverbindingen door Servlets, en wat dan nog meer... _{hopelijk trap ik nu niemand in z'n maag met deze uitspraak}

Nog een vraagje (ben nu toch bezig )
Voor een opdrachtje voor mezelf wil ik voor een web applicatie de requests door één centraal punt laten lopen. Dus als iemand een request doet voor ene page dat een bean/Servlet (welke??) het volgende doet:
1) kijkt of een user ingelogd is (mbv een sessie)
2) als dit niet zo is, de user doorstuurt naar de login page
3) als alles goed is de user doorstuurt naar de aangevraagde page
Zou moeten kunnen allemaal, maar komt allemaal weer neer op mijn 1e vraag:
Wanneer en waarvoor gebruik je een bean of Servlet?

misschien zijn er nog wel wat mede-GoT'ers die dit wel willen weten (en anders weten ze het al en mogen ze het mij vertellen )

[Verwijderd]

Beans zouden je in feite een hoop werk uit handen moeten nemen wat betreft request processing, validation en persistence zodat je je bij je programmeer werk op de business logic kunt richten.

Allemaal leuk en aardig, maar tenzij je een applicatie gaat schrijven voor honderden/duizenden users zijn beans IMO gewoon overkill en heb je tegen de tijd dat je beans een beetje onder de knie hebt waarschijnlijk je applicatie al lang klaar met servlets (tenminste, ik dan ).

Wat ik ook minder vind aan beans is dat het moeilijk is om het overzicht te behouden zonder een goede IDE. Beans zijn IMO hetzelfde verhaal als Struts, het is allemaal leuk uitgedacht en het werkt ook, maar zonder goede tools zal het gebruik ervan eerder de ontwikkeling van je programma in de weg staan dan dat het echt wat bijdraagd.

[yrew]

Er is wel een heel groot verschil tussen Enterprise Java Beans en Java Beans. Maak je gebruik van Enterprise Java Beans (EJB) dan regelt de bean container allerlei zaken voor je. Binnen de EJB's heb je dan ook weer verschillende EJB's.

Je hebt SessionBeans (deze bevatten voornamelijk bussinesslogic (zouden dan ook per user geinstantieerd kunnen worden om hiermee alle requests van een sessie(user) af te kunnen handelen). Deze kunnen an sich ook weer statefull en stateless zijn.

Je hebt Entitybeans deze bevatten voornamelijk al je objecten. Vaak zie je per tabel in je database een vertaling naar entitbeans.

Je hebt ook message driven beans, deze maken o.a asynchrone communicatie en dataverwerking mogelijk.

Java Beans zijn stukken software die voldoen aan een bepaalde blueprint. Deze blueprint maakt het mogelijk om Java Beans met groot gemak in te passen in je huidige software, ook veel ide's hebben de mogelijkheid om Java Beans te registreren. Zo kun je heel snel en makkelijk user interface componenten toevoegen aan je werkomgeving.

[ Voor 36% gewijzigd door yrew op 07-11-2003 09:22 ]

[TheRebell]

Ja het verschil tussen JavaBeans en EJB's weet ik wel. Wat ik dus hier zou gebruiken zijn JavaBeans. EJB's zouden een overkill zijn.

Als beans (JavaBeans) ook al een overkill zouden zijn, waarom doen ze er in die boeken dan zoveel mee Daar doen ze meer mee dan met Servlets. Daarom is het gewoon onduidelijk wanneer je de keuze hebt tussen een oplossing met beans en met Servlets.
Met een Servlet zou je bv een connectionpool kunnen maken, een bean zou je kunnen gebruiken om de gebruikersinvoer van een formulier te kunnen laten controleren....maar waarom kan het ook niet andersom..
Als je een toepassing/functionaliteit in je hoofd hebt kun je dus die 2 keuzen maken, het lijkt mij dat dat een gestructureerde keuze is en niet op de manier van "..oh ik gebruik maar Servlets, die had ik nog niet.."

[Stephan Oudmaijer]

TheRebell schreef op 07 november 2003 @ 09:38:
Ja het verschil tussen JavaBeans en EJB's weet ik wel. Wat ik dus hier zou gebruiken zijn JavaBeans. EJB's zouden een overkill zijn.

Als beans (JavaBeans) ook al een overkill zouden zijn, waarom doen ze er in die boeken dan zoveel mee Daar doen ze meer mee dan met Servlets. Daarom is het gewoon onduidelijk wanneer je de keuze hebt tussen een oplossing met beans en met Servlets.
Met een Servlet zou je bv een connectionpool kunnen maken, een bean zou je kunnen gebruiken om de gebruikersinvoer van een formulier te kunnen laten controleren....maar waarom kan het ook niet andersom..
Als je een toepassing/functionaliteit in je hoofd hebt kun je dus die 2 keuzen maken, het lijkt mij dat dat een gestructureerde keuze is en niet op de manier van "..oh ik gebruik maar Servlets, die had ik nog niet.."

Je moet een onderscheid maken tussen presentatie en business logica. Beans zijn je business logica object, Servlets/JSP`s zijn je View!

Een framework zoals struts gebruikt een model 2 architechtuur, dit houdt in, een controller class(servlet), jsp`s voor de view en beans voor de business logica.

Gebruik je puur een jsp/servlet om html te displayen, met een bean om wat dingen voor je te doen, dan heb je te maken met een model 1 architechtuur.

Gewone beans draaien op een locale VM, kunnen dus alleen aangesproken worden door applicaties op 1 computer, normale beans doen ook niet aan state-management. Wil je bijvoorbeeld vanaf meerdere servers of meerdere vm`s gebruik maken van 1 bean dan moet je aan EJB`s gaan denken. Deze draaien op een (applicatie)server en zijn via het netwerk te benaderen.

Eigenlijk komt het er op neer dat: welke java componenten je gebruikt heeft veel(alles) te maken met de architechtuur die je kiest.

Als je echt met jsp`s bezig bent zou ik je zeker aanbevel om struts te gaan gebruiken, er zijn tal van redenen te waarom je het kan gebruiken, ik zou zeggen gebruik google maar eens :-)

[ Voor 6% gewijzigd door Stephan Oudmaijer op 07-11-2003 09:58 ]

[Verwijderd]

Nou waarom EJB's redenen

- snelle time to market
- 3 tier system, DB, logic en UI zijn gescheiden <- servlets = 2 tier DB en de rest
- wanneer goed gedesigned is de performance beter!
- gemakkelijk servertje naast te zetten
- is stabieler wanneer web app 24/7 moet draaien
- gevoelige info worden beter gemanaged... EJB zijn niet gemakklijk hackabel
- houden rekening met security isues (encription)
- webpage heeft geen direct toegang tot de DB je geeft dus niet je database structuur weg.
- oja voordat er weer eens een discussie komt over hoe langzaam entity beans zijn een goed design maakt gebruik van fasade en local entity beans. als dat geen goede oplossing is kan er altijd JDO (Java data objects) worden gebruikt

[yrew]

TheRebell schreef op 07 november 2003 @ 09:38:
Ja het verschil tussen JavaBeans en EJB's weet ik wel. Wat ik dus hier zou gebruiken zijn JavaBeans. EJB's zouden een overkill zijn.

Als beans (JavaBeans) ook al een overkill zouden zijn, waarom doen ze er in die boeken dan zoveel mee Daar doen ze meer mee dan met Servlets. Daarom is het gewoon onduidelijk wanneer je de keuze hebt tussen een oplossing met beans en met Servlets.
Met een Servlet zou je bv een connectionpool kunnen maken, een bean zou je kunnen gebruiken om de gebruikersinvoer van een formulier te kunnen laten controleren....maar waarom kan het ook niet andersom..
Als je een toepassing/functionaliteit in je hoofd hebt kun je dus die 2 keuzen maken, het lijkt mij dat dat een gestructureerde keuze is en niet op de manier van "..oh ik gebruik maar Servlets, die had ik nog niet.."

Ik denk dat webswansj bedoelde dat EJB's een overkill zijn. Alleen in dat geval wordt er werk voor je uit handen genomen, alleen moet je daar wel je hele omgeving voor op inrichten. Beans zijn geen overkill.

In jouw geval kun je voor het afhandelen van requests zowel gebruik maken van een bean als van een servlet. Er zijn geen redenen waarom de een beter zou zijn dan de ander.

[TheRebell]

nee nee ik ga geen gebruik maken van EJB's, daarvoor is het te simpel

Je kunt kiezen tussen een aantal MVC-modellen:
1) alleen JSP (en wat JavaBeans):
M= JavaBeans, V= JSP, C= JSP
2) JSP/Servlets:
M= JavaBeans, V= JSP, C = Servlets
3) JSP/Servlets/EJB
M = JavaBeans & entity EJB, V = JSP, M = Servlets & Session EJB

Ik wil dus denk ik meer een modelletje 2 gaan toepassen. Connectionpooling gaat alleen met Servlets (correct me if i'm wrong) dus die moet ik hebben. JavaBeans gebruik je dus eigenlijk altijd wel volgens de modellen.

JavaBeans bevatten de business logic, maar wat is dan business logic
Volgens de boeken is dat ook al het controleren van een formuliertje....
En een Servlet zou alle requests moeten verwerken ofzo.....

[TheRebell]

yrew schreef op 07 november 2003 @ 10:30:
[...]
*knip*
In jouw geval kun je voor het afhandelen van requests zowel gebruik maken van een bean als van een servlet. Er zijn geen redenen waarom de een beter zou zijn dan de ander.

Dus dan maakt het geen ruk uit wat je nou gebruikt, lijkt me dat dat ook niet helemaal de bedoeling ervan is. Blijft lekker vaag dan wanneer & voorwat je nou een JavaBean of een Servlet gebruikt

[yrew]

TheRebell schreef op 07 november 2003 @ 10:46:
[...]

Dus dan maakt het geen ruk uit wat je nou gebruikt, lijkt me dat dat ook niet helemaal de bedoeling ervan is. Blijft lekker vaag dan wanneer & voorwat je nou een JavaBean of een Servlet gebruikt

Ik zeg niet dat dat nooit te bepalen is. Zoals ck terecht opmerkt zul je voor je views (in web-wereld) geen maken van beans. Hiervoor zijn namelijk servelts en jsp's(=servlet) beter geschikt.

Echter voor invoer-controle, request afhandeling etc kun je ze beide gebruiken.

[yrew]

Bussiness logic = het gebied tussen User Interfase en Database

[ Voor 179% gewijzigd door yrew op 07-11-2003 11:05 ]

[TheRebell]

yrew schreef op 07 november 2003 @ 11:02:
Bussiness logic = het gebied tussen User Interfase en Database

dus oa request processing, input validation, database connection.... en dat kan een servlet ook...maar een bean ook....

Ik moet de scheiding dus meer zien ahv de speficaties dan aan een gerichte keuze, omdat een Servlet iets niet kan wat een JavaBean weer wel kan (of andersom)

...ahum...in het boek van Sun staat een lijstje...
Servlet job's :
1) read the explicit data send by the client
2) read the implicit HTTP request data sent by the browser
3) generate the result
4) send the explicit data (i.e. the document) to the client
5) send the implicit HTTP response data

Grof gezegd verwerkt een Servlet dus requests en responses en maakt hiervoor gebruik van andere Servlets (bv conn.pooling) , JavaBeans (bv validating) en JSP (voor de output)
..begin ik het nu al een beetje te snappen of niet
In principe zou je dus altijd een Servlet moeten/willen gebruiken als toegangspoortje voor je web applicatie. Tenzij je natuurlijk puur JSP's gebruikt

[Verwijderd]

misschien een goed idee om eens naar "Struts" te kijken.... maakt het leven echt een stuk eenvoudiger vergeleken met zelf bouwen van JSP/servlets

[TheRebell]

Verwijderd schreef op 07 november 2003 @ 12:20:
misschien een goed idee om eens naar "Struts" te kijken.... maakt het leven echt een stuk eenvoudiger vergeleken met zelf bouwen van JSP/servlets

Mjah, ik heb het eerst liever op de 'gewone' manier onder de knie, daarna kan ik wel naar zo'n oplossing kijken.
Ik moet ook een onderwijs case maken, en daarvoor gaat struts een beetje te ver dusja...

Als ik nu een Servlet gebruik als algeheel toegangspunt (de deur tot de applicatie ), dan moet die Servlet kijken welke page je aanvraagd, kijken of jijdaar toe bevoegd bent (hoe gaat dat nou weer ) en daarna doorsturen naar de aangevraagde page of evt de login page.
Dan moet die Servlet toch wel weten welke page's beveiligd zijn, dus dat zulje op de page zelf moeten declareren. Een lijst in de Servlet (evt db) bijhouden lijkt me nu ook niks...

Servlets<->JavaBeans zijn een klein stukje helderder, in principe is er dus niet echt een vaste keuze die je maakt (voor deze functionaliteit moet je een Servlet hebben, enz..)
Een Servlet verwerkt requests en responses en een bean kan de Servlet hierbij helpen en gegevens controleren. Zoiets

[Stephan Oudmaijer]

TheRebell schreef op 07 november 2003 @ 12:31:
[...]

Mjah, ik heb het eerst liever op de 'gewone' manier onder de knie, daarna kan ik wel naar zo'n oplossing kijken.
Ik moet ook een onderwijs case maken, en daarvoor gaat struts een beetje te ver dusja...

Als ik nu een Servlet gebruik als algeheel toegangspunt (de deur tot de applicatie ), dan moet die Servlet kijken welke page je aanvraagd, kijken of jijdaar toe bevoegd bent (hoe gaat dat nou weer ) en daarna doorsturen naar de aangevraagde page of evt de login page.
Dan moet die Servlet toch wel weten welke page's beveiligd zijn, dus dat zulje op de page zelf moeten declareren. Een lijst in de Servlet (evt db) bijhouden lijkt me nu ook niks...

Servlets<->JavaBeans zijn een klein stukje helderder, in principe is er dus niet echt een vaste keuze die je maakt (voor deze functionaliteit moet je een Servlet hebben, enz..)
Een Servlet verwerkt requests en responses en een bean kan de Servlet hierbij helpen en gegevens controleren. Zoiets

kijk nou eerst eens naar struts en naar form-based security, hoef je het wiel niet zelf opnieuw uit te vinden, wat je nu wel wilt doen.

een jsp als controller is trouwens niet echt handig :-) (wat je hierboven schreef) Een servlet als controller (wat struts dus al is) kan dit veel beter. Wil je toch zelf het wiel uitvinden gebruik dan een Servlet als control laag tussen je jsps(view) en je domein(beans).

struts biedt veel meer voordelen, o.a. form-validatie. ik raad je toch sterk aan eens naar struts te kijken, hier een leuke starters tutorial:

http://rzserv2.fhnon.de/~lg002556/struts/Struts_Tutorial.pdf

succes

[Verwijderd]

Even voor de goede orde. Ga je toevallig werken bij Quinity TheRebell?

[TheRebell]

Verwijderd schreef op 07 november 2003 @ 13:40:
Even voor de goede orde. Ga je toevallig werken bij Quinity TheRebell?

..uhh..nee... Maar verklaar je nader

[Verwijderd]

Nou dit soort dingen zijn precies de dingen die je thuis moet doen als je bij hen wil gaan werken (voortraject. Dus ik dacht eveneens een nieuwe werknemer te spreken. Maar daar zat ik dus naast.

[TheRebell]

Verwijderd schreef op 07 november 2003 @ 13:53:
Nou dit soort dingen zijn precies de dingen die je thuis moet doen als je bij hen wil gaan werken (voortraject. Dus ik dacht eveneens een nieuwe werknemer te spreken. Maar daar zat ik dus naast.

Nee sorry
Misschien is Quinity wel iets voor mn afstuderen.... Net even op de site gekeken en dat doen jullie ook

[Verwijderd]

Tja, ik weet niet welke opleiding je doet? Ik bedoel welk niveau? En per wanneer je dat wil doen, en vooral in welke hoek je het wil doen...Eveneens kan je er dan wellicht blijven werken. Het is een mooi bedrijf voor startende mensen. Klein/stabiel maar wel groeiende !

[TheRebell]

Verwijderd schreef op 07 november 2003 @ 13:59:
Tja, ik weet niet welke opleiding je doet? Ik bedoel welk niveau? En per wanneer je dat wil doen, en vooral in welke hoek je het wil doen...Eveneens kan je er dan wellicht blijven werken. Het is een mooi bedrijf voor startende mensen. Klein/stabiel maar wel groeiende !

Kunnen we misschien beter eens over mailen ipv hier alles posten (gaat ook nogal off-topic op deze manier)

Op even op de rest terug te komen
CK ik wil geen struts gaan gebruiken Sorry, jij vindt van wel maar ik wil het eerst op deze manier allemaal voor elkaar krijgen en als ik daarvoor het wiel opnieuw moet uitvinden...so be it... (wordt het wel mn eigen wiel )

Nou volgens SUN is een oplossing met JSP's als controller het 1e model, oke handig is het misschien niet maar dit is de manier die je zou moeten toepassen als je puur JSPs wilt gebruiken (oke en wat beans)

Wat ik me nu nog afvraag, dat verhaal van Servlets en beans wordt allemaal al een stuk duidelijker door de goeie reacties hier , is hoe je Servlet (als toegangspoort) gaat kijken of de opgevraagde pagina een beveiligde pagina is of niet. Zo ja dan zou er gekeken moeten worden, door de Servlet, of de user is ingelogd en anders een login pagina sturen ipv de aangevraagde pagina...

[yrew]

Je kunt alle pagina's in een xml bestand zetten en hierin aangeven op welke niveau's ze beschikbaar zijn. Heel basic zou je twee niveau's kunnen nemen. niveau 0 kun je zonder login bereiken. Niveau 1 kun je met login bereiken. In de toegangs servlets kun je nu, als er een request komt voor een bepaalde pagina kijken wat de atributen van die pagina zijn. Zit de pagina op niveau 1 en is de gebruiker niet ingelogged (een tabel met ingelogde ip's) dan wordt er verwezen naar login.html etc etc.

Uiteraard kun je meer en meer niveaus aanbrengen als je dit wilt. Dit is ook maar 1 oplossing en er zijn er meer.

[Bobco]

TheRebell schreef op 07 november 2003 @ 14:09:
[...]
Wat ik me nu nog afvraag, dat verhaal van Servlets en beans wordt allemaal al een stuk duidelijker door de goeie reacties hier , is hoe je Servlet (als toegangspoort) gaat kijken of de opgevraagde pagina een beveiligde pagina is of niet. Zo ja dan zou er gekeken moeten worden, door de Servlet, of de user is ingelogd en anders een login pagina sturen ipv de

Puntje vooraf: ik heb de thread niet in detail doorgelezen, dus het kan zijn dat ik iemand na ga blaten...

Voor een opzet met al dan niet beveiligde pagina's kun je prima een Filter gebruiken. Eigenlijk is dit een gespecialiseerde vorm van een Servlet. Een Filter hangt in een filterchain en krijgt een request binnen zoals een Servlet die ook binnenkrijgt. Het handige aan Filters is dat je ze kunt stapelen door in een url-mapping aan te geven of een request door een filter moet of niet. Voorbeeldje:

code:

<filter-mapping>
  <filter-name>InlogFilter</filter-name>
  <url-pattern>/secured/*</url-pattern>
</filter-mapping>

Dit lijkt natuurlijk heel veel op de manier waarop je Servlets op URLs mapt, maar op deze manier kun je elke request voor een beveiligde pagina (die allemaal onder /secured hangen binnen je applicatie) door je inlog filter laten lopen. Die bekijkt vervolgens of de user is ingelogd etc.

[TheRebell]

die oplossingen van yrew en bobco klinken wel interessant, al denk ik dat ik de laatste ga gebruiken. Maar zoals yrew al zegt zijn er meerdere mogelijkheden.

Ik was al op zoek naar een filter-achtig iets en zag ook een klein stukje daarover in mn boekje staan. Dat filter, wordt dan ook elker keek doorlopen bij een request of moet je dat expliciet zelf doen?

Tannie kun je misschien je mail adres geven, dan kunnen we eens wat uitwisselen?

[edit]
Hmm, dat filter wordt dus gebruikt als jij een page aanroept die binnen dat pattern valt. Dan zou je dus in dat filter weer moeten zeggen wat ie dan moet doen.. Helaas staat de uitleg daarover in een ander boek, volume 2 (boek is core servlets & jsp)

[ Voor 23% gewijzigd door TheRebell op 07-11-2003 15:16 ]

[Bobco]

TheRebell schreef op 07 november 2003 @ 15:09:

Ik was al op zoek naar een filter-achtig iets en zag ook een klein stukje daarover in mn boekje staan. Dat filter, wordt dan ook elker keek doorlopen bij een request of moet je dat expliciet zelf doen?

De webcontainer zorgt voor de aanroep van je filter. het enige dat je hoeft te doen een class te schrijven die de Filter interface implementeert. Daar heb je maar drie methods voor nodig:

Java:

public class LoginFilter implements Filter {

  public void init() {
  // do init stuff
  }

  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    // cast request to HttpServletRequest, get Session and user object
    if (user.isLoggedIn()) {
      chain.doFilter(request, response)
    } else {
    // put requested URL in session and redirect to login page
    }
  }
  public void destroy() {
  // do cleanup
  }
}

Je Filter krijgt van de container het request en response object. Het enige verschil ten opzichte van een Servlet is dat je het volgende Filter in de FilterChain moet aanroepen als je de request voor de URL verder wilt afhandelen. Het mooie van Filters is dat je ze kunt stapelen: je kunt makkelijk een hele serie Filters een request laten behandelen. Je kunt bijvoorbeeld een teller filter maken dat gewoon elke request telt.

[Stephan Oudmaijer]

TheRebell schreef op 07 november 2003 @ 14:09:
[...]

Op even op de rest terug te komen
CK ik wil geen struts gaan gebruiken Sorry, jij vindt van wel maar ik wil het eerst op deze manier allemaal voor elkaar krijgen en als ik daarvoor het wiel opnieuw moet uitvinden...so be it... (wordt het wel mn eigen wiel )

Nou volgens SUN is een oplossing met JSP's als controller het 1e model, oke handig is het misschien niet maar dit is de manier die je zou moeten toepassen als je puur JSPs wilt gebruiken (oke en wat beans)

model 1 architechtuur heeft geen controller class.

model 2 (bijv struts) gebruikt servlets voor de controller laag.

[TheRebell]

CK schreef op 07 november 2003 @ 16:17:
[...]


model 1 architechtuur heeft geen controller class.

model 2 (bijv struts) gebruikt servlets voor de controller laag.

Daar denkt mn O'Reilly boek anders over...

1) alleen JSP (en wat JavaBeans):
M= JavaBeans, V= JSP, C= JSP
2) JSP/Servlets:
M= JavaBeans, V= JSP, C = Servlets
3) JSP/Servlets/EJB
M = JavaBeans & entity EJB, V = JSP, M = Servlets & Session EJB

Bij model 1 is een JSP page dus de view maar is een JSP page ook een controller. Natuurlijk niet dezelfde maar hij fungeert wel als een...

Boek:
The MVC model makes sense even for a pure JSP play. I recommend that you use separate JSP pages for presentation and request processing, and place all business logic in beans. Let controller pages initialize the beans, and let view pages generate the response by reading their properties.

wat je dan wel haal handig kunt doen....

Boek:
...follow this model, it's easy to move to a combination of Servlets and JSP the day you find that the pure JSP aplication is becomming hard to maintain

Dan ga je dus over op een JSP/Servlet (+beans) oplossing.
Tuurlijk is de eerste oplossing niet zo mooi en begin je liever bij model 2, dat snap ik ook nog wel

[Verwijderd]

Het kan zijn dat ik een hele alternatieve aanpak heb, maar persoonlijk gebruik ik servlets voor de business logic, die servlets stoppen alles wat door de JSPs gepresenteerd moet worden (de view) in beans. Beans zijn, zoals ik ze gebruik, dus slechts data overdragers. De database is dan dus feitelijk het model (en de beans veelal een afspiegeling daarvan), in de beans zelf zit geen tot weinig logica.

Is dit raar?

[Verwijderd]

CK schreef op 07 november 2003 @ 16:17:
[...]


model 1 architechtuur heeft geen controller class.

model 2 (bijv struts) gebruikt servlets voor de controller laag.

Nou dit is echt waanzin... je kan altijd een controller laag bouwen! het enige wat je wel kan af vragen is de methode die je wilt toepassen wel de beste weg naar Rome

[TheRebell]

Verwijderd schreef op 07 november 2003 @ 17:49:
Het kan zijn dat ik een hele alternatieve aanpak heb, maar persoonlijk gebruik ik servlets voor de business logic, die servlets stoppen alles wat door de JSPs gepresenteerd moet worden (de view) in beans. Beans zijn, zoals ik ze gebruik, dus slechts data overdragers. De database is dan dus feitelijk het model (en de beans veelal een afspiegeling daarvan), in de beans zelf zit geen tot weinig logica.

Is dit raar?

mwoh, wat is raar ...maar gezien de denkwijze van Mr Sun is het 'raar' ja. Maargoed, als het zo goed werkt en je vindt het makkelijk op deze manier, waarom anders doen

Als ik eens wat lees over dat Filteren, dan zegt mijn boekje dat je het eigenlijk niet zo moet doen maar gebruik moet maken van de authenticatie in de web container...

[edit]
dat bedoelde ik nou ook Marik2000

[ Voor 4% gewijzigd door TheRebell op 07-11-2003 22:01 ]

[Verwijderd]

Omdat er nogal wat onduidelijkheden waren over wat een model is, hier mijn mening:

Als model van een applicatie denk ik vaak aan de (bedrijfs) logica. Dus bijvoorbeeld dat 1 post in een forum 0 of meer replies heeft, etc. Het model heeft de verantwoordelijkheid om de informatie in je applicatie consistent te houden. Dus dat een post geen forums kan bevatten en dat een post altijd een subject moet hebben. Tevens kan het model persistency implementeren, zodat je na een herstart, nieuwe request, etc. met de zelfde data verder kunt. Een goed model wordt zo opgezet dat het zoveel mogelijk herbruikbaar is. Van een groupware web applicatie zou zonder veel moeite een swing/WML/etc. applicatie gemaakt moeten kunnen worden. HTML code, HTTP responses, enz. zou dus niet teruggevonden mogen worden in het model.

Mijn bedrijfslogica zit toch al in het relationeel schema van de database?
In het relationeel schema zit inderdaad de datastructuur van de bedrijfslogica. Maar er komt veel meer kijken bij de bedrijfslogica. Naar ons forum voorbeeld: Wanneer is een topic "hot" (zo'n flammetje komt er dan vaak bij ) Dit kan in databases (moeilijk/niet) vastgelegd worden. Dit wordt niet in controller en/of viewer geimplementeerd, omdat er dan op meerdere plaatsen het zelfde staat. Dit heeft natuurlijk weer meer bugs en hogere onderhoudskosten tot gevolg.

Form validation in Servlet/JSP/JavaBean?
Er zijn verschillende soorten form validation. De simpele form validation (of een veld ingevuld is, uit minimaal 8 tekens bestaat, etc. doe ik vaak in Servlets. Het model gaat ervan uit dat een e-mail adres aan een bepaald formaat voldoet.
Maar of het email adres geregistreerd is als abonnee, dat is bedrijfslogica. Die check komt dus in het model (JavaBean). Over het algemeen kun je vaak zeggen dat, wanneer de controlle afhankelijk is van gegevens uit de bedrijslogica (b.v. bestaande posts, users, etc.) dit geimplementeerd dient te worden in het model. De checks worden meestal niet binnen het model uitgevoerd (behalve als pre- en postcondities), maar aangeroepen vanuit de controller en/of view. Dus voorbeeld stukje code uit een controller:

code:

if(username == null || password == null) { // Check in controller geimplementeerd
  // show error
}else if(model.isValidUser(username,password) { // Check in model geimplementeerd
   model.loginUser(username,password);
   // show page
}else{
   // show error
}

Maar hoe wordt de informatie consistent gehouden?
Door gebruik te maken van programming by contract. Door pre- en postcondities en class-invariants en daar waar nodig ook hierop te checken is het onmogelijk om vanuit een controller de informatie corrupt te maken. De gegevens in de persistency laag (b.v. db of legacy systeem) zullen dus vanuit de controllers en views niet corrupt kunnen raken.

Waarom persistency in model afhandelen?
Dit is handig, de controllers en views hoeven niet na te denken over waar ze de gegevens vandaan moeten halen. Bij 2 schermen waar berichten worden weergegeven uit 1 database tabel zouden SQL-queries of JDBC statements kunnen staan. Als i.p.v. een database dan een legacy systeem gebruikt gaat worden, of tabelnamen wijzigen, etc. dan moet de code op meerdere plaatsen bijgewerkt worden en is er een grotere kans op fouten.
Nadeel van persistency in het model is dat alle views en controllers getest moeten worden als de persistency methode wordt gewijzigd. Daarom is het handig om bij de views en controllers alleen de interface van het model bekend te maken (of abstracte classes) en dan de persistency zelf in subclasses van het model te implementeren.

Het model zo maken dat het geschikt is voor andere toepassingen is overhead!
Dit lijkt wel zo te zijn. Maar hiervoor heb ik een aantal tegenargumenten:
- Je weet nooit welke technieken straks gebruikt worden. Cobol programmeurs van de vorige eeuw wisten toen ook niet dat hun applicaties later gebruikt gingen worden voor web applicaties (b.v. bij Rabobank)
- Je denkt beter na over het model. Door de scheiding tussen model, views en controllers wordt er beter nagedacht over het model en ligt de nadruk niet op specifieke implementaties (html code, swing forms, etc.)

User validatie
Owja, voor degenen die user validation willen gaan implementeren met JSP/Servlet technologie. De servlet specificatie bevat al decleratieve security. Dit is dus op 1 plaats definieren, met minder kans op fouten, lagere ontwikkel en onderhoudskosten.

Hopelijk hebben jullie d'r wat aan

[TheRebell]

hmm ik heb nog wel wat vraag/op/aanmerkingen, zeker over dat form validatie. Beans zijn daar namelijk nogal goed in en implementeren daarvoor wat handige functionaliteitjes tov hetzelfde met Servlets. Helaas moet ik zo snel gaan treinen dus zal het pas morganavond worden

Qua validatie kan de web container een hoop leuke dingen doen iig, dat beloof wat

[Verwijderd]

TheRebell schreef op 08 november 2003 @ 19:15:
hmm ik heb nog wel wat vraag/op/aanmerkingen, zeker over dat form validatie. Beans zijn daar namelijk nogal goed in en implementeren daarvoor wat handige functionaliteitjes tov hetzelfde met Servlets. Helaas moet ik zo snel gaan treinen dus zal het pas morganavond worden

Qua validatie kan de web container een hoop leuke dingen doen iig, dat beloof wat

Aannemende dat je met Beans de JavaBeans bedoelt, waarom zijn ze er goed in? En welke functionaliteitjes implementeren ze? In de spec kan ik hier namelijk niets over vinden.

Owja, ben je hier voor een opdracht van school mee bezig en zo ja, welke school zit je dan? HEN toevallig?

[ Voor 8% gewijzigd door Verwijderd op 09-11-2003 15:01 . Reden: Vraagje toegevoegd ]

[TheRebell]

Nee is niet voor de HEN, is voor de AIM (Hogeschool Brabant)

Nou een bean implementeert een aantal zeer handige dingentjes als getter en setter, auto type conversie en beschikt standaard over de request en response.
Een servlets standaard niet, uiteraard kun je dat wel toevoegen maarja, als een bean dat standaard allemaal implementeerd

Ook hebben ze dr in dat boek nogal over dat je beans daarvoor gebruikt, dusja...wie ben ik dan om dat niet te doen

[Verwijderd]

Bij het maken van een JavaBean moet je je inderdaad aan onder andere de get/set/is conventie houden. Maar je zult het nog wel zelf moeten implementeren . Ze zijn hierdoor wel duidelijker en beter te hergebruiken.(b.v. met JSTL) En een standaard request en response heb je toch in een Servlet? Volgens mij heeft een servlet onder andere een doGet en doPost methode met de parameters request en response. En als dat in het boek staat, welk boek is dat dan eigenlijk?

Handige best practice

[TheRebell]

Het boek is JavaServer Pages van O'Reilly. Di ehemeren vanaf het begin nogal op JSTL. Daarom heb ik er nog ff 1 gehaald, Core Servlets & JavaServer Pages (Marty Hall)

Wat je zegt klopt wel, ik had ene kleine fout gemaakt. Een Servlet beschikt idd standaard over request en response. Een bean beschikt echter standaard over de methoden om gegevens aan te nemen (getter, setter) en type conversie.

Het is allemaal iig iets duidelijker, dat wel. Leuke discussies geweest met een docent. Die is wel niet zo technisch maar laat je dr wel goed over nadenken

[flowerp]

Ik ben zelf ook bezig met J2EE applicaties, maar vraag me af of het niet beter is om standaard checks (velden wel ingevuld, email address juiste vorm enz) client side af te handelen.

Natuurlijk, het kan makkelijk met javabeans in jsp's (of desnoods met rechtstreeks code in jsp, maar dat vind ik zelf iets minder mooi). Echter... je belast dan wel je server en netwerk voor dingen die de server helemaal niet nodig hebben.

Nou was ik bezig te kijken hoe ik die client side check het beste kan doen. Javascript ligt voor de hand, maar veel liever zou ik het client side ook met beans doen zodat ik eventueel nog dingen kan heen en weer schuiven tussen client en server.

Wat ik eigenlijk zoek is een methode om javabeans client-side net zo te gebruiken als je ze server-side gebruikt. Dus gewoon iets als <jcp:getProperty name="book" property="title" /> waarmee dan een string op een page gezet kan worden. Javascript kan dit wel, terwijl die stomme applets alleen maar dingen in een hokje kunnen tekenen.