3 Tier programmeren met Java hoe hoort het?

[Verwijderd]

Hallo Tweaker,

op dit moment ben ik begonnen met mijn afstuderen en wil daarom graag een 3 Tier applicatie gaan ontwikkelen in combinatie met Java RMI en een SQL server.

Nu kun je natuurlijk de vraag stellen waarom 3 Tier en niet 2 Tier maar das gewoon een overweging die ik heb gemaakt om het Multi-user verhaal, realtime etc gemakkelijk te kunnen implementeren.

Echter wat ik me nu afvraag hoe doen jullie dat in combinatie met de database, ga je gewoon weg steeds nadat je wat wijzigt deze verandering in je geheugen doorvoeren en vervolgens naar een database een soort van backup wegschrijven. Dus addObject daar in dan een Insert Into van de database. En alle if statement etc gewoon door de server uit laten voeren op zijn geheugen. Of is het juist raadzaam om voor alles de database te benaderen en zo weinig mogelijk met de objecten op de server te werken.

Dit lijkt me dan weer tegen het object georienteerd programmeren ingaan.

kortom ik vraag me af hou jullie programmeurs dit soort problemen op lossen en of hiervoor gouden regels/ of leesvoer voor is.

Ik ben benieuwd

[whoami]

-> SE&A

[whoami]

Eh, wat bedoel je nu eigenlijk ?

Normaal gezien ga je een record uit de DB halen, dat je in een object stopt. Dat object wordt gewijzigd, en als de gebruiker zegt 'Save', ga je de wijzigingen wegschrijven in je DB.

Je Data Access layer is verantwoordelijk om de gegevens uit je DB te trekken, je UI zorgt ervoor dat je de wijzigingen kan maken, de BL zorgt ervoor dat er geen onzin in komt te staan, en je DAL is er verantwoordelijk voor om je object terug goed naar de DB weg te schrijven. _{in een notedop}

[Tubby]

Voor de database laag moet je eens verdiepen in het DAO design pattern, wellicht icm Hibernate.

[Verwijderd]

whoami schreef op vrijdag 16 juni 2006 @ 10:53:
Eh, wat bedoel je nu eigenlijk ?

Normaal gezien ga je een record uit de DB halen, dat je in een object stopt. Dat object wordt gewijzigd, en als de gebruiker zegt 'Save', ga je de wijzigingen wegschrijven in je DB.

Je Data Access layer is verantwoordelijk om de gegevens uit je DB te trekken, je UI zorgt ervoor dat je de wijzigingen kan maken, de BL zorgt ervoor dat er geen onzin in komt te staan, en je DAL is er verantwoordelijk voor om je object terug goed naar de DB weg te schrijven. _{in een notedop}

Ja precies dat is wat ik eigenlijk dacht. Mijn DB levert bij een opstart van de server alle gegevens aan hiervan maak deze de object. Vervolgens kun de clients deze opvragen en wijzige. Drukken ze op wijzige dan wordt naast het wijzige van het object op de server ook de wijziging na de DB geschreven. Hierdoor funceert de DB eigenlijk alleen om de data op te slaan en terug te geven.

Maar als ik dan vragen query ga uitvoeren kan ik die dus net zo goed als IF AND statements op de server uitvoeren en zo de objecten terug geven naar de client toch?

Of is dat nu juist wat ik niet moet doen en moet ik dat soort vragen weer rechtstreeks aan de DB gaan vragen in combinatie met bv PL/SQL?

Dat is eigenlijk wat ik me in deze fase van onderzoek ben aan het afvragen

[Verwijderd]

Tubby schreef op vrijdag 16 juni 2006 @ 10:55:
Voor de database laag moet je eens verdiepen in het DAO design pattern, wellicht icm Hibernate.

Je bedoelt Observer, Strategie, Singelton, Facade, Adapter, enz

Deze heb ik allemaal nammelijk al een keer toegepast. Of bedoel je hiervoor andere Desing Patterns

[ Voor 7% gewijzigd door Verwijderd op 16-06-2006 11:07 ]

[whoami]

Verwijderd schreef op vrijdag 16 juni 2006 @ 11:01:
[...]


Ja precies dat is wat ik eigenlijk dacht. Mijn DB levert bij een opstart van de server alle gegevens aan hiervan maak deze de object. Vervolgens kun de clients deze opvragen en wijzige. Drukken ze op wijzige dan wordt naast het wijzige van het object op de server ook de wijziging na de DB geschreven. Hierdoor funceert de DB eigenlijk alleen om de data op te slaan en terug te geven.

Bij de opstart van de server ga je dus je hele DB in het geheugen gaan laden ?
Waarom ? Wat ga je doen als user A een record wijzigt en user B vraagt nadien dat object op ? Wat gaat user B zien ? Het object incl. de wijzigingen ?

Maar als ik dan vragen query ga uitvoeren kan ik die dus net zo goed als IF AND statements op de server uitvoeren en zo de objecten terug geven naar de client toch?

Je bedoelt Observer, Strategie, Singelton, Facade, Adapter, enz

Deze heb ik allemaal nammelijk al een keer toegepast. Of bedoel je hiervoor andere Desing Patterns

Ja, je kan wel leuk met termen gooien, maar deze design patterns zijn op een lager niveau toepasbaar.
Wat Tubby zegt, is dat je gebruik kunt maken van het DAO pattern (dat afaik in de Java wereld best veel gebruikt wordt), en met Hibernate de O/R mapping kunt doen.

Sorry, maar ik heb zo het idee dat je de klok wel hoort luiden, maar geen idee hebt waar de klepel hangt ?

_{let aub ook even op je spelling, en gebruik de edit-knop ipv 2x direct na elkaar te posten}

[ Voor 27% gewijzigd door whoami op 16-06-2006 11:15 ]

[momania]

Verwijderd schreef op vrijdag 16 juni 2006 @ 11:01:
[...]
Maar als ik dan vragen query ga uitvoeren kan ik die dus net zo goed als IF AND statements op de server uitvoeren en zo de objecten terug geven naar de client toch?

Je wilt dus eigenlijk de objecten die je van de database gegevens hebt, gecached houden en daar in zoeken ipv te querien op de database

Lijkt met niet echt verstandig. Als je caching van database gegeven wilt gebruiken zijn daar al wel goede frameworks voor. Kijk bv een naar Hibernate icm EHCache of JBoss cache.

[JKVA]

Verwijderd schreef op vrijdag 16 juni 2006 @ 11:07:
[...]
Je bedoelt Observer, Strategie, Singelton, Facade, Adapter, enz

Deze heb ik allemaal nammelijk al een keer toegepast. Of bedoel je hiervoor andere Desing Patterns

Hij doelt waarschijnlijk op de core j2ee patterns, zoals deze hier staan:

http://java.sun.com/blueprints/corej2eepatterns/Patterns/

[Verwijderd]

whoami schreef op vrijdag 16 juni 2006 @ 11:13:
[...]

Bij de opstart van de server ga je dus je hele DB in het geheugen gaan laden ?
Waarom ? Wat ga je doen als user A een record wijzigt en user B vraagt nadien dat object op ? Wat gaat user B zien ? Het object incl. de wijzigingen ?

Ja dat want ik wijzig eerst het object in het geheugen op de server en schrijf het daarna weg in de database. Op moment dat gebruiker A een record wijzigt op de Server en gebruiker B vraagt dit op dan krijg gebruiker B het object uit geheugen van de server terug in dit geval dus gewijzigt door A.

Dit zou geen probleem op lever zonder database erbij, want op moment dat systeem loopt werkt dit echt ik dacht weg te schrijven na de database om problemen te voorkomen bij een systeem crach.

Zo hebben we dat altijd gedaan, maar dat is voor mijn gevoel niet hoe het zou moeten vandaar dit topic.

Want als ik gewoon mijn data veilig wil stellen zou ik dit ook kunnen doen door een ObjetOutputstream te gebruiken.

[Alarmnummer]

Je spreekt over tiers als je onderdelen verspreid zijn over verschillende processen (dus verschillende machines of verschillende vm's). Er vind dan remote communicatie plaats.

Je spreekt over layers je met een lagen structuur werkt. Voorwaarde voor een lagen structuur is dat een laag nooit afhankelijk is van een boven liggende laag en alleen afhankelijk is van de laag direct onder hem (en niet afhankelijk van de lagen daaronder).

Layers kun realiseren met tiers, maar dat is dus niet noodzakelijk. Schaalbare applicaties kan je vaak ook uitstekend opzetten zonder tiers. Dus zorg ervoor dat je goed weet wat je precies wilt.. Layers zijn vaak goed... tiers zijn vaak bad.

Zorg verder dat je Patterns of Enterprise Application Architecture in je bezit krijgt. Dat is een boek dat iedere zichzelf respecterende developer gelezen moet hebben imho.

[ Voor 21% gewijzigd door Alarmnummer op 16-06-2006 11:35 ]

[Verwijderd]

Alarmnummer schreef op vrijdag 16 juni 2006 @ 11:32:
Je spreekt over tiers als je onderdelen verspreid zijn over verschillende processen (dus verschillende machines of verschillende vm's). Er vind dan remote communicatie plaats.

Je spreekt over layers je met een lagen structuur werkt. Voorwaarde voor een lagen structuur is dat een laag nooit afhankelijk is van een boven liggende laag en alleen afhankelijk is van de laag direct onder hem (en niet afhankelijk van de lagen daaronder).

Layers kun realiseren met tiers, maar dat is dus niet noodzakelijk. Schaalbare applicaties kan je vaak ook uitstekend opzetten zonder tiers. Dus zorg ervoor dat je goed weet wat je precies wilt.. Layers zijn vaak goed... tiers zijn vaak bad.

Zorg verder dat je Patterns of Enterprise Application Architecture in je bezit krijgt. Dat is een boek dat iedere zichzelf respecterende developer gelezen moet hebben imho.

MM Oke ga een weekend weg dus nog snel even naar de schoolbieb boekje score :-P, en als ik dus goed begrijp krijg ik met mijn Systeem dus wel te maken met 3 tiers, want ja ik heb client die met de server in verbinding staan via RMI en de server kan weer met de Database praten.

Maar moet me dus niet blind gaan staren op lagen want A ik gebruik die term verkeerd en B is niet noodzakelijk om een schaalbare applicatie te maken. Spreken hier trouwens dadelijk over een systeem waarop ongeveer 20 client de hele dag moeten werken

[H!GHGuY]

nog een anekdote de wereld uithelpen:
als een object op de server aangepast wordt moet ie niet altijd onmiddellijk in de DB gepersisteerd worden. Waar heb je die server anders voor ?

bekijk ook alleszins nog eens Model-View-Controller vooraleer je begint

[Alarmnummer]

Verwijderd schreef op vrijdag 16 juni 2006 @ 11:16:
[...]
Ja dat want ik wijzig eerst het object in het geheugen op de server en schrijf het daarna weg in de database. Op moment dat gebruiker A een record wijzigt op de Server en gebruiker B vraagt dit op dan krijg gebruiker B het object uit geheugen van de server terug in dit geval dus gewijzigt door A.

Ik weet niet precies wat je wilt bouwen dus ik weet ook niet of het daarom handig is om data in het geheugen te houden.

Maar wat ik meestal doe om concurrency problemen op te lossen is te werken met immutability en isolation. Immutable objecten zijn per definitie niet vatbar voor concurrency issues. Isolated objects zijn ook niet vatbaar voor concurrency issues omdat ze geisoleerd leven van andere threads.

Alle concurrency control (nodig voor de isolation) kun je dan het beste laten verlopen mbv je database transactie.

Verder kun je gebruik maken van allerlei caching opties om onnodig db toegang te verhinderen, maar ga niet vanaf het 1e moment al lopen te optimaliseren (met als gevolg een slecht ontwerp).

Wat wil je eigelijk gaan maken? Want ik heb zo de indruk dat je verkeerde keuzes neemt doordat je niet goed weet wat er mogelijk is en wat de vaak gebruikte oplossingen zijn.

[Alarmnummer]

Verwijderd schreef op vrijdag 16 juni 2006 @ 11:40:
MM Oke ga een weekend weg dus nog snel even naar de schoolbieb boekje score :-P, en als ik dus goed begrijp krijg ik met mijn Systeem dus wel te maken met 3 tiers, want ja ik heb client die met de server in verbinding staan via RMI en de server kan weer met de Database praten.

Maar moet me dus niet blind gaan staren op lagen want A ik gebruik die term verkeerd en B is niet noodzakelijk om een schaalbare applicatie te maken. Spreken hier trouwens dadelijk over een systeem waarop ongeveer 20 client de hele dag moeten werken

Maar wat voor client wil je? Kan het een browser icm html zijn? Of wil iets mbv een rich client api bakken zoals Swing?

[Verwijderd]

Alarmnummer schreef op vrijdag 16 juni 2006 @ 11:42:
[...]

Maar wat voor client wil je? Kan het een browser icm html zijn? Of wil iets mbv een rich client api bakken zoals Swing?

Het gaat om een Change Request systeem. Dus een request waarop alle afdelingen veranderingen moeten doorvoeren zeer veel attributen maar opzich maar 4 grote basis objecten.

Ik wilde geen gebruik maken van HTML of ASP.net omdat ik veel met tabelen kom te werken. En dan bedoel ik het principe user maken een nieuwe Rij aan in een tabel vullen die en op moment dat ze op enter drukken direct weer een nieuwe rij, daarnaast moet er uit voer naar Excel plaats vinden.

Wel ben ik ook het een en ander over JSP en Servlets aan lezen omdat ik verwacht dat deze ook mogelijkheden kunnen bieden. Zelf heb ik nu al een volledig RMI Veiling systeem moeten bouwen dus heb hier al wat ervaring opgedaan. Maar daar schreven we de data weg in dat bestanden.

Om en het overschrijf probleem wilde ik als volgt oplossen. De kans op overschrijving is laag omdat per afdeling maar 1 iemand ervoor verantwoordelijk is. Echter om toch een veiligheid in te bouwen

Wilde ik op moment dat ik een form laad dit aanpas en wegschrijf moet de oorspronkelijke data die bij laden geladen was vergeleken worden met de huidige data op de server. Als hier nu een verschil in zit moet de gerbuiker hierop gewezen worden wat de verschillen zijn en of overschrijven doorgevoerd mag worden.

[ Voor 21% gewijzigd door Verwijderd op 16-06-2006 11:50 ]

[Verwijderd]

HIGHGuY schreef op vrijdag 16 juni 2006 @ 11:41:
nog een anekdote de wereld uithelpen:
als een object op de server aangepast wordt moet ie niet altijd onmiddellijk in de DB gepersisteerd worden. Waar heb je die server anders voor ?

bekijk ook alleszins nog eens Model-View-Controller vooraleer je begint

Heb het boek nu on mijn bezit en zal hoofstuk 14 eens goed onder de loep nemen

[Alarmnummer]

Verwijderd schreef op vrijdag 16 juni 2006 @ 11:47:
[...]


Het gaat om een Change Request systeem. Dus een request waarop alle afdelingen veranderingen moeten doorvoeren zeer veel attributen maar opzich maar 4 grote basis objecten.

Ik wilde geen gebruik maken van HTML of ASP.net omdat ik veel met tabelen kom te werken. En dan bedoel ik het principe user maken een nieuwe Rij aan in een tabel vullen die en op moment dat ze op enter drukken direct weer een nieuwe rij, daarnaast moet er uit voer naar Excel plaats vinden.

Kan allemaal perfect via HTML. Je moet niet vergeten dat een client niet veel anders kan renderen dan HTML, dat je serverside JSP gebruikt is voor de browser totaal onbelangrijk.

Voordeel verder aan HTML is dat je geen client applicaties hoeft te installeren en dat iedereen met een browser er dus bij kan komen.

En er zijn genoeg API's (zoals JExcel) waarmee het dood eenvoudig is om runtime excel sheets te genereren en die te laten downloaden door de user.

Wel ben ik ook het een en ander over JSP en Servlets aan lezen omdat ik verwacht dat deze ook mogelijkheden kunnen bieden. Zelf heb ik nu al een volledig RMI Veiling systeem moeten bouwen dus heb hier al wat ervaring opgedaan.

Ik zou het hele ideee van 'tiers' een beetje laten varen.

Persoonlijk zou ik gaan voor Servlets die direct met je service laag praten (de laag die al jouw taken kan uitvoeren zoals 'plaatsOrder' 'maakNieuwGebruikerAan' ). Deze service laag praat op zijn beurt weer met een domain laag (dus daar vind je objecten zoals Order, Gebruiker etc) en die kan mbt DAO`s spul van en naar de db sturen. Je service laag is ook de laag waarop je security en transacties kunt coordineren (zie dat boek). Verder is het werken met Servlets wel redelijk naad. Daarom werk je vaak met een webframework zoals Struts, Spring-MVC, JSF, Tapestry, Wicket (is voor jou denk ik wel een aanrader).

vb:

code:

interface ChangeDao{
    void delete(long changeId);
}

interface JdbcChangeDao implements ChangeDao{
    void delete(long changeId){
       ... some jdbc stuff
    }
}

interface ChangeManager{
   void delete(long changeId);
}

class ChangeManager implements ChangeManager{
   private ChangeDao changeDao;

    void deleteChange(long changeid){
       changeDao.delete(changeId);
    }
}

class DeleteChangeController extends SomeController{
    private ChangeManager changeManager;

    ModelAndView submit(HttpRequest req, HttpResp resp){
         long changeId = RequestUtils.getRequiredLong(req,"changeId");
         changeManager.delete(changeId);
    }
}

Zoals je kunt zien heb je hier een controller: DeleteChangeController (je presentation laag). DIe krijgt webrequests binnen (en daarin zie de changeId die je wilt deleten). Deze controller geeft dan aan de changeManager (je service laag). Vervolgens zie je de ChangeManager de delete doorgeven aan de DAO en de DAO die verwijdert het uit de db.

[ Voor 29% gewijzigd door Alarmnummer op 16-06-2006 12:02 ]

[Tubby]

Verwijderd schreef op vrijdag 16 juni 2006 @ 11:47:
[...]


Het gaat om een Change Request systeem. Dus een request waarop alle afdelingen veranderingen moeten doorvoeren zeer veel attributen maar opzich maar 4 grote basis objecten.

Ik wilde geen gebruik maken van HTML of ASP.net omdat ik veel met tabelen kom te werken. En dan bedoel ik het principe user maken een nieuwe Rij aan in een tabel vullen die en op moment dat ze op enter drukken direct weer een nieuwe rij, daarnaast moet er uit voer naar Excel plaats vinden.

Wel ben ik ook het een en ander over JSP en Servlets aan lezen omdat ik verwacht dat deze ook mogelijkheden kunnen bieden. Zelf heb ik nu al een volledig RMI Veiling systeem moeten bouwen dus heb hier al wat ervaring opgedaan. Maar daar schreven we de data weg in dat bestanden.

Uitvoer naar excel is geen reden om niet voor ASP.net te kiezen, want deze kan dat net zo goed als JSP/Servlets dat kunnen. Het willen hebben van editable grid is wel een factor om voor een rich internet app te kiezen (ajax of flash) of voor een java swing client. Verder zou het persisten van je data ("schreven de data weg in dat bestanden") los moeten staan van je business logic.

Om en het overschrijf probleem wilde ik als volgt oplossen. De kans op overschrijving is laag omdat per afdeling maar 1 iemand ervoor verantwoordelijk is. Echter om toch een veiligheid in te bouwen

Wilde ik op moment dat ik een form laad dit aanpas en wegschrijf moet de oorspronkelijke data die bij laden geladen was vergeleken worden met de huidige data op de server. Als hier nu een verschil in zit moet de gerbuiker hierop gewezen worden wat de verschillen zijn en of overschrijven doorgevoerd mag worden.

Magoed, voor iemand die "Je bedoelt Observer, Strategie, Singelton, Facade, Adapter, enz" al eens heeft geimplementeerd ben je behoorlijk verloren.

Als ik jou was zou ik deze patterns nog maar een keer aflopen want er zitten wel wat bruikbare tussen voor jouw applicatie. Jouw probleem is dat je al te veel denkt in technische implementatie terwijl je eerst je architectuur duidelijk moet hebben.

[ Voor 3% gewijzigd door Tubby op 16-06-2006 11:58 ]

[Verwijderd]

Alarmnummer schreef op vrijdag 16 juni 2006 @ 11:53:
[...]

Kan allemaal perfect via HTML. Je moet niet vergeten dat een client niet veel anders kan renderen dan HTML, dat je serverside JSP gebruikt is voor de browser totaal onbelangrijk.

Voordeel verder aan HTML is dat je geen client applicaties hoeft te installeren en dat iedereen met een browser er dus bij kan komen.

En er zijn genoeg API's (zoals JExcel) waarmee het dood eenvoudig is om runtime excel sheets te genereren en die te laten downloaden door de user.


.

Dat heb ik toch wel eens geprobeert in ASP.net en daarbij had ik toch het probleem dat ik iedere rij die ik wilde aanpassen eerst moest aanklikken dan moet openen, dan ging ie die rij klaar maken om aan te mogen passen, en dan moest ik die weer sluiten. Moest ik dan een nieuwe rij dan duurde dat weer lang.

Waarbij een Applicatie dat zeer snel deed.

Maar ik ga me naast het lezen van het boek ook een verder verdiepen in servlets, ik kreeg nammelijk het idee dat ik via servlets juist echt de hele applicatie in een browser werkend kon krijgen. Heb dat al eens geprobeerdt met applets maar dat vond ik helemaal niets.

[Tubby]

Verwijderd schreef op vrijdag 16 juni 2006 @ 11:58:
[...]


Dat heb ik toch wel eens geprobeert in ASP.net en daarbij had ik toch het probleem dat ik iedere rij die ik wilde aanpassen eerst moest aanklikken dan moet openen, dan ging ie die rij klaar maken om aan te mogen passen, en dan moest ik die weer sluiten. Moest ik dan een nieuwe rij dan duurde dat weer lang.

Waarbij een Applicatie dat zeer snel deed.

Maar ik ga me naast het lezen van het boek ook een verder verdiepen in servlets, ik kreeg nammelijk het idee dat ik via servlets juist echt de hele applicatie in een browser werkend kon krijgen. Heb dat al eens geprobeerdt met applets maar dat vond ik helemaal niets.

...servlets werken daarin niet veel beter of slechter dan ASP.net, zoals Alarmnummer uitlegt zijn het beide server side scripting talen die clientside in grote lijnen dezelfde html produceren.

Waar jij naar moet gaan kijken is AJAX of Flash als je dit perse in een webapplicatie wilt gaan realiseren.

[Verwijderd]

Tubby schreef op vrijdag 16 juni 2006 @ 11:57:

Magoed, voor iemand die "Je bedoelt Observer, Strategie, Singelton, Facade, Adapter, enz" al eens heeft geimplementeerd ben je behoorlijk verloren.

Als ik jou was zou ik deze patterns nog maar een keer aflopen want er zitten wel wat bruikbare tussen voor jouw applicatie. Jouw probleem is dat je al te veel denkt in technische implementatie terwijl je eerst je architectuur duidelijk moet hebben.

Ja verloren ben ik zeker . Ik heb in de afgelopen 3 jaar zoveel patterns, technieken RMI, Corba talen enz gehad dat je op een gegeven moment niet meer weet hoe je wat moet oplozen. Je zoekt het veel te moeilijk of kiest juist altijd voor de jou best liggende maneir terwijl andere weer beter zijn.

Je probeert het wel goed te doen, maar is soms lastig als je denkt. Is niet ow we bouwen wel even wat als je goed wilt doen en doordacht.

Maar ik ga in ieder geval eens kijken naar wat jullie allemaal voorstellen en zeggen, en ook nog een rustig de topic doorlezen want er staat al best veel dingen in waar ik meer info over wil en moet zoeken

[Alarmnummer]

Ik heb bij mijn vorige reply nog even een code voorbeeld gezet zodat je een beetje een idee hebt.

[Tubby]

Verwijderd schreef op vrijdag 16 juni 2006 @ 12:06:
[...]
Maar ik ga in ieder geval eens kijken naar wat jullie allemaal voorstellen en zeggen, en ook nog een rustig de topic doorlezen want er staat al best veel dingen in waar ik meer info over wil en moet zoeken

Dit is het beste wat je op dit moment kan doen, onderzoek

[Cuball]

Verwijderd schreef op vrijdag 16 juni 2006 @ 11:58:
[...]
Dat heb ik toch wel eens geprobeert in ASP.net en daarbij had ik toch het probleem dat ik iedere rij die ik wilde aanpassen eerst moest aanklikken dan moet openen, dan ging ie die rij klaar maken om aan te mogen passen, en dan moest ik die weer sluiten. Moest ik dan een nieuwe rij dan duurde dat weer lang.
Waarbij een Applicatie dat zeer snel deed.

ik denk dat je hierin overdrijft, volgens mij kan je de meeste gebruiker interacties onder 1 seconde houden (als je gaat bewaren, zoeken kan dit wat langer duren, maar met optimalisaties mag dit nog niet zoveel schelen)

en als je echt geen roundtrips naar de server wil maken moet je kijken om het via javascript asyncroon te doen achter te schermen (ajax)

[Alarmnummer]

Weet de topic starter al hoe hij het probleem wil oplossen?

[Verwijderd]

Alarmnummer schreef op zaterdag 17 juni 2006 @ 01:48:
Weet de topic starter al hoe hij het probleem wil oplossen?

De Topic starter is terug van zijn weekendje weg .

En heeft eens goed zitten nadenken maar een keuze maken in dit stadium hoe precies ga doen weet ik nog niet helemaal. Eerst ga ik zeer nauwkeurig mijn pakket van eisen opstellen met de gebruikers. ik heb na aanleiding van dit topic wel weer terug overweging die ik eerst aan de kant had geschoven.

Maar tot nu toe lijk ik te gaan kiezen voor servlets hierin ga ik me nu eerst meer verdiepen en kijken hoever ik dit begrijp en of ik de stap durf te maken om hierin aan de slag te gaan.

[Tubby]

Verkeerde volgorde imho
- Eerst kijken wat je wil (functioneel)
- Dan kijken hoe je het gaat doen (talen, tools, patterns)

[Verwijderd]

Tubby schreef op maandag 19 juni 2006 @ 15:32:
Verkeerde volgorde imho
- Eerst kijken wat je wil (functioneel)
- Dan kijken hoe je het gaat doen (talen, tools, patterns)

Ja heb je ook gelijk in klopt. Maar doen jullie dat dan ook echt niet.

Je begint de gesprekken wat er nodig is en in je hoofd begin je al te malen wat moet ik nu eigenlijk gaan doen. Toen dacht ik mm en ik moet dat dadelijk vrij snel bepalen. Dus kan ik nu al wat info in winnen. En al zo om me heen gaan lezen hoe en wat.

Want ik mis gewoon nog te veel ervaring om dadelijk 1,2,3 een keuze te maken zonder eerst goed me erin te verdiepen