VO com parametro tipo Object ou simples

This message was edited 1 time. Last update was at 22/01/2009 10:25:23

Ola,

Estou criando um VO "Value Object", mas tenho a dúvida se devo criar as variaveis membro como tipo simples ou composto. Exemplo:

int tamanho;
ou
Integer tamanho;

Ja li algumas vezes que a especificaçao do EJB definia que para transferir VO's era necessario sempre usar Objects devido o fator Serializaçao, mas no caso qdo era a especificaçao do EJB 1.1 ate 2.0 quando usavam os protocolos RMI e Corba.

Depois que mudou pro XML-RPC no EJB 2.1 - 3.0, creio que isso ja nao afeta mais tanto, mas nao sei!
Vejo que muitas vezes alguns servidores conseguem trabalhar com o VO's com tipo simples, mas acredito que quando temos algum processo de balanceamento de carga, ou diversos classloaders trabalhando junto os tipos simples nao consigam ser repassados ou armazenados.

Digo isto pq o Hibernate, JAXB e outros framework usam Object como Tipo para representar os dados.

Qual seria a sugestao ou modelo ideal?

abrs

Acho que usar Objeto tipo que virou padrão de mercado, mesmo que não precise mais, mas ate ainda é usado..eu iria de "Integer"

This message was edited 1 time. Last update was at 22/01/2009 10:50:39

Opa!

Um grande ponto que vejo, e que um Objeto gasta bem mais memoria do que usar um tipo simples... Imagina se vc tem umas 40 variaveis membro no VO. rs....

Fora a chatisse de ficar convertendo de simples para composto os valores, toda a hora que precisa calcular algo...

Por isso, pergunto se existe alguma necessidade como antigamente no Corba ou EJB Remotos!

abrs

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

Não é simples ou composto. É tipo primitivo (int) ou wrapper (Integer).

Se você estiver na dúvida, dê preferência ao tipo primitivo, o motivo não são detalhes de baixo nível (você parece obcecado com isso), é mais questão de consistência.

Exemplos:
1. Esse código é válido:

Esse não é válido:

Quando você tenta fazer isso:

vai dar NullPointerException, e normalmente não aparece a linha do erro, pra complicar mais as coisas. Ter sempre as variáveis com tipo primitivo previne a criação de números "nuláveis".

2.
Eu tenho um método assim:

Isso é válido:

Isso não é válido:

3. Tenho dois métodos sobrecarregados:

Se eu chamar, assim:

Pra evitar problemas assim, use os wrappers somente quando necessário, por exemplo, nas Collections.

converter? qual versao do java vc usa? que gasta mais memoria é verdade..mas vc vai fazer um sistema web? ou pra celular?

Thread.start() Membro desde: 08/01/2009 08:23:56 Mensagens: 40 Offline

Hola Leo4001,

Mas antigamente pela especificaçao do EJB 1.1 a 2.0, tipo primitivo nao era permitido por causa do Remote.

Ai pergunto se existe algo assim ainda? Acredito que se estamos no mesmo container e se nao ocorrer nenhum processo de Serializaçao nao teriamos problema..

Nao e questao da versao java e nem do padrao de mercado, e entender que podemos sempre otimizar algo ao Máximo![/b]

abrs

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

joaosiqueira wrote:Hola Leo4001,

Mas antigamente pela especificaçao do EJB 1.1 a 2.0, tipo primitivo nao era permitido por causa do Remote.

Ai pergunto se existe algo assim ainda? Acredito que se estamos no mesmo container e se nao ocorrer nenhum processo de Serializaçao nao teriamos problema..

Nao e questao da versao java e nem do padrao de mercado, e entender que podemos sempre otimizar algo ao Máximo![/b]

abrs

A otimização que você coloca é baseado no recurso da linguagem (VO) VALUE OBJECT ?, ou que a VM pode suportar ou um software que possa dar essa retaguarda na carga de objetos ? ou situação baixa granularidade ou baixa coesão.; - Outra coisa sobre a especificação J2EE usada e o que permita remote não seria viável algo que produza independência da linguagem não seria mais interessante algo como Spring ao invés de pensar em EJBs, não sairia melhor na otimização.

This message was edited 1 time. Last update was at 23/01/2009 07:26:11

Ola Marcio Duran,

Gostaria apenas de entender se usar objetos no VO é realmente necessario!

O que é esse OFBIZ no seu logo?

abrs

GUJ Master Membro desde: 23/01/2008 11:14:35 Mensagens: 1905 Offline

joaosiqueira wrote:Ola Marcio Duran,
Gostaria apenas de entender se usar objetos no VO é realmente necessario!

Sim é necessário:A transfer object is a serializable class that groups related attributes, forming a composite value. This class is used as the return type of a remote business method. Clients receive instances of this class by calling coarse-grained business methods, and then locally access the fine-grained values within the transfer object. Fetching multiple values in one server roundtrip decreases network traffic and minimizes latency and server resource usage.

Sample:

Fontes

Fonte Link explicação

Fonte aplicação VO na pratica

O que é esse OFBIZ no seu logo?
abrs

OFbiz é o maior projeto Open Source para desenvolvimento em ERP totalmente desenhado em Java, onde trás todo o Core de Projetos Frameworks da Apache Jakarta, solução de ponta e alta tecnologia, utiliza POJO SOA egine, utiliza especificação para trabalhar novas features incluindo Grovvy .
Um FrameWork de negócio já com um start do zero já com módulos workflows projetados Open Source ERP, Open Source CRM, Open Source E-Business / E-Commerce, Open Source SCM, Open Source MRP, Open Source CMMS/EAM, uma revolução para larga produtividade.Não é um "FrameWork só técnico já monta o seu negócio do ZERO", um grande diferencial.

Grovvy interoperabilidade com Beanshell

http://docs.ofbiz.org/pages/viewpage.action?pageId=4472

Introdução Basica modulo e visualização do ERP

http://open-ils.org/dokuwiki/lib/exe/fetch.php?id=scratchpad%3Aacq_serials&cache=cache&media=scratchpad:woodchip_guide.pdf

Notícias, artigos e o maior fórum brasileiro sobre Java