Here's what I've commented on this issue:

I think the purpose of Transfer Object Pattern , where it says it wants to 
reduce remote calls between tiers over the network is related to tiers like 
client / server architectures.

This means that:

i) A Swing client requests a query on a table for a remote EJB
ii) The EJB executes two calls on the database
ii.a) select count(*)
ii.b) select * ... limit x offset y / rownum between z and k // whatever DB 
paging technique is being used.
iii) Put all this information into one single Transfer Object
iv) Send the object back to the client application over the network

So, if your Web Application is running on the same server with your services 
(EJBs, Spring Services, whatever), this means that you are not going to 
transport data over the network between those tiers (Web and Model). And there 
will be an "implicit" Transfer Object to the real client (web browser).

Following this logic: -1 for this improvement.

Regards,
Bruno

-----Mensagem original-----
De: rgoodwin [mailto:[EMAIL PROTECTED]
Enviada em: quarta-feira, 26 de novembro de 2008 19:01
Para: [email protected]
Assunto: RE: Is there any other way? DataProviders must hit the Db twice
for (possible) large datasets



Still is being disputed unfortunately :(

https://issues.apache.org/jira/browse/WICKET-1784

For those who believe in the 1-query approach, ergo the DTO pattern, writing
an alternative to the Wicket data provision using a DTO approach isn't a
terrible hardship ... just annoying to be sprung with on day one of using
Wicket. But pain is experienced later when encountering the Wicket data
provision and paging mechanism coupling. The paging mechanism is far less
joy to replace ...

IReallyHateDataProvider



Hoover, William wrote:
> 
> I think the idea behind this is that size will be called first. If the
> size is zero there is no need to proceed with the call to get the items.
> I don't necessarily agree with this approach because a lot of service
> calls can capture the data in one call (even down to the database level-
> some support getting the size/results in one call), but the last time I
> brought this issue up it was disputed.
> 

-- 
View this message in context: 
http://www.nabble.com/Is-there-any-other-way--DataProviders-must-hit-the-Db-twice-for-%28possible%29-large-datasets-tp20701684p20708929.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

***************************************************************************************************
"Atenção: Esta mensagem foi enviada para uso exclusivo do(s) destinatários(s) 
acima identificado(s),
podendo conter informações e/ou documentos confidencias/privilegiados e seu 
sigilo é protegido por 
lei. Caso você tenha recebido por engano, por favor, informe o remetente e 
apague-a de seu sistema.
Notificamos que é proibido por lei a sua retenção, disseminação, distribuição, 
cópia ou uso sem 
expressa autorização do remetente. Opiniões pessoais do remetente não refletem, 
necessariamente, 
o ponto de vista da CETIP, o qual é divulgado somente por pessoas autorizadas."


"Warning: This message was sent for exclusive use of the addressees above 
identified, possibly 
containing information and or privileged/confidential documents whose content 
is protected by law. 
In case you have mistakenly received it, please notify the sender and delete it 
from your system. 
Be noticed that the law forbids the retention, dissemination, distribution, 
copy or use without 
express authorization from the sender. Personal opinions of the sender do not 
necessarily reflect 
CETIP's point of view, which is only divulged by authorized personnel."
***************************************************************************************************


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to