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” 
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 
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:
- Esse código é válido:
Integer i1 = null;
Esse não é válido:
int i2 = null; // não compila!
Quando você tenta fazer isso:
Integer i1 = null;
int i2 = i1 // unboxing
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”.
-
Eu tenho um método assim:
void meuMetodo(long param);
Isso é válido:
int valor1 = 10;
meuMetodo(valor1);
Isso não é válido:
Integer valor2 = 10; // boxing
meuMetodo(valor2); // não compila, só é permitido unboxing para int
- Tenho dois métodos sobrecarregados:
public void meuMetodo(Object obj) {
System.out.println("Objeto");
}
public void meuMetodo(int i) {
System.out.println("Inteiro");
}
Se eu chamar, assim:
Integer v1 = 10;
int v2 = 10;
t.meuMetodo(v1); // imprime "Object", não "Inteiro"
t.meuMetodo(v2); // imprime "Inteiro"
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?
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 
[quote=joaosiqueira]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 [/quote]
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.
Ola Marcio Duran,
Gostaria apenas de entender se usar objetos no VO é realmente necessario!
O que é esse OFBIZ no seu logo?
abrs 
[quote=joaosiqueira]Ola Marcio Duran,
Gostaria apenas de entender se usar objetos no VO é realmente necessario!
[/quote]
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
:arrow:Fonte Link explicação
:arrow:Fonte aplicação VO na pratica
[quote]
O que é esse OFBIZ no seu logo?
abrs [/quote]
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
:arrow:http://docs.ofbiz.org/pages/viewpage.action?pageId=4472
Introdução Basica modulo e visualização do ERP
:arrow:http://open-ils.org/dokuwiki/lib/exe/fetch.php?id=scratchpad%3Aacq_serials&cache=cache&media=scratchpad:woodchip_guide.pdf
