[J2EE|Swing] Waar models te maken

[PhoneTech]

Ik ben bezig met een swing applicatie wat moet samenwerken met een J2EE applicatie. De client moet lijsten van de server op kunnen vragen. Een object uit zo een lijst wordt samengesteld uit meerdere cmp's op de server, en dit neemt ook wat processing time in beslag.

Nu kunnen deze lijsten behoorlijk groot worden (1000 tot 10000 rijen, hangt van de context af) en moet de client dit natuurlijk wel effecient opvragen.

Nu zijn er verschillende scenarios te bedenken:

Het data model met alle objecten op de server samen stellen en als een blok naar de client sturen

of

Een count doorgeven naar de client, en dan de client per rij het object op de server laten samenstellen in invoegen in het model (zou wel mooi werken met progress listeners)

of

Een simplistische lijst laten weergeven op de client, en dan puur met master/detail views werken

Nu is de laatste optie wel het makkelijkste, maar ik weet nu al dat de engineers van detail houden, en graat lijsten bekijken met daarin zo veel mogelijk relevante data.

Zou ik alle wetten breken als ik het model op de server opbouw en dat binnenhaal om daar vervolgens de views en de controllers op aan te sluiten?

Volgens mij is de 2de optie het eleganst omdat je dan ook precies de status van de te laden objecten mooi kan bijhouden

Wat is jullie mening hier over?

[Alarmnummer]

Is het noodzakelijk om alle objecten in 1 keer naar de client te sturen? Ik neem aan dat de client niet zoveel heeft aan een lijst met 1000 tot 10.000 items.. Is het daarom niet handiger als je de client iedere keer een verzoek laat doen voor een pagina (bv 10 t/m 19). Eventueel zou je stiekum als je op de 2e pagina zit meteen de 3e al ophalen om zo de gebruiker niet zo lang te laten wachten.

[ Voor 20% gewijzigd door Alarmnummer op 22-03-2005 21:54 ]

[PhoneTech]

Alarmnummer schreef op dinsdag 22 maart 2005 @ 21:46:
Is het noodzakelijk om alle objecten in 1 keer naar de client te sturen? Ik neem aan dat de client niet zoveel heeft aan een lijst met 1000 tot 10.000 items.. Is het daarom niet handiger als je de client iedere keer een verzoek laat doen voor een pagina (bv 10 t/m 19).

Dan maak ik liever gebruik van een fast data readers. De gebruiker moet ook instaat zijn om filters in te stellen. Misschien is het handiger om de client gebruiker eerst de filter in te laten stellen, en dan de gefilterde results terug te geven....

[PhoneTech]

Heeft iemand nog andere ideeen hier over?

[Verwijderd]

Toevallig zat ik laatst met hetzelfde punt.
Het voordeel van de hele lijst in een keer naar de client sturen is dat dingen als filteren sorteren sneller gaan, aangezien hier niet weer eerst met de server gecommuniceerd hoeft te worden.
Het nadeel is uiteraard dat er nogal veel data verstuurd moet worden.

Wat ik heb gedaan is meteen gaan performance testen.
Het resultaat is overduidelijk, het is beter (sneller) om kleine stukjes data van de server op te vragen.

Bij een aantal duizend rijen (werden verstuurd in een arraylist) duurde het al vrij lang voordat ik het resultaat op de client binnen had.
Bij meer dan 20.000 liep de client vast, en bij meer dan 100.000 kreeg de server een "out of heap space" error.

Nu stuur ik een hele specifieke aanvraag naar de server, inclusief filters etc, en dat gaat supersnel.
Ik ben dus voor je laatste optie.

[PhoneTech]

Ik ga het als volgende opzetten

In den beginne wordt helemaal geen lijst gedownload. De gebruiker kan een filter in stellen,of er voor kiezen om de hele lijst in 1 keer te downloaden. per ingestelde filter wordt een nieuwe lijst binnengehaald. dit zal de server ook wel ontlasten, omdat deze alleen entiteiten hoeft op te bouwen die in de filter gedefinieerd zijn....Lijkt mij een goed plan toch?

[PhoneTech]

Zo...Even een followup.

Client side maak ik een filter aan. en de client stuurt de filter naar de server en haalt dan de data op. De snelheid is te doen, maar het kan nog flink verbeterd worden.

door bijvoorbeeld geen

code:

public List getRelatedComments(GrootObject go)

maar

code:

public List getRelatedComments(String pkGrootObject)

Nu lijkt dat geen bal uit te maken, maar als je dit een paar honderd keer achter elkaar doet, krijg je minder dataverkeer enzo. Ook hoef ik binnen dezelfde request serie elke keer geen findByPrimaryKey te doen ombij de CMP relaties te komen...

Alle kleine beetjes helpen natuurlijk.

Maar nu komt er nog een vraag (modje, misschien topic titel aanpassen)

Ik heb verschillende interpretaties van mijn objecten in de client. Mijn objecten zijn in stukken gehakt dus ik kan het volgende doen in mijn datamodel

code:

entitydatamodel.initComments
entitydatamodel.initKeywords
entitydatamodel.initXXX

en ga zo maar door. De functies halen de data op en zet ze in mijn datamodel om vervolgens gebruikt te gaan worden.

Dit heeft een behoorlijke wild groei van init methoden opgebracht. En het object dient al 1 keer te zijn ingeladen voordat je de init methoden kan uitvoeren.

Nu heb ik het idee om een soort load strategy op te gaan zetten. Heb wel een idee waarbij je deze implementatie krijgt op de server:

code:

getEntityList(Filter filter, LoadStrategy loadStrategy)

getEntity(String PK, LoadStrategy loadStrategy

waarbij de LoadStrategy een object is waarin een zooi booleans staat die aangeven welke delen ingeladen moeten worden.

Ik heb wel wat informatie gevonden over deze problematiek, maar het meeste gaat objecten waarbij je maar 1 presentatie van het object hebt. -> http://java.sun.com/bluep...erns/CompositeEntity.html

Het Lazy Load gebeuren gaat dus niet op denk ik omdat bij het request pas weet wat ik wil inladen..
.

Heeft iemand tips, strategieen om dit probleem te tackelen?

[ Voor 12% gewijzigd door PhoneTech op 26-06-2005 22:35 ]