| Autor |
Mensagem |
|
|
Ola Marcio Duran,
Gostaria apenas de entender se usar objetos no VO é realmente necessario!
O que é esse OFBIZ no seu logo?
abrs 
|
 |
|
|
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 
|
|
|
|
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 
|
|
|
|
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
|
|
|
|
Marcio Duran,
So trazendo o mundo hacking no GUJ.. eheheh
muito bom!!! 
|
|
|
|
Site bloqueado e coisa de amador, cade o espirito hacker pra driblar essa porcaria de firewall da empresa??
Fala serio meu,.,.
|
|
|
|
Valeu Marcio Duran,
Esse artigo de Reflections me ajudou bastante.
Obrigado!
|
|
|
|
Nossa esse post foi demais, o que gerou de debate e polemica...
Isso prova como algo simples pode se tornar complexo, devido a amplitude de recursos de uma boa linguagem de prograçao.
Abraços a todos!
|
|
|
|
|
dddd
|
|
|
|
Ola Marcio Duran,
Os serviços em que me refiro fiz sao classes POJO.
Vc tb utiliza static em serviços SOA?
abraços
|
|
|
|
Victorwss,
Sua explicaçao foi demais, tenho q admitir... gostei!
Em que momentos vc acha que deveria utililizar um metodo static? Pois atualmente utilizo em metodos de classe de serviços de negocio, classes utilitarias e algumas vezes em blocos static para inicializaçao de valores.
O processo de carga de uma classe em uma Reflection e o mesmo que um static? Pois sempre dizemos que uma Reflection e lento, e o melhor seria utilizar o new diretamente no código em tempo de compilçao e nao execuçao.
Obrigado pela força!
abraços
|
|
|
|
Ola thingol,
Opa, me confundi, e Reflaction que quiz dizer mesmo!!
O Reflaction utiliza o mesmo processo de carga que um static? Pois os dois sao cargas de classes feitas pela VM na memória...
abraços
|
|
|
|
Qualquer experimentaçao só existe pq alguem usou alguma logica...
A tipica frase: Penso, logo, existo... Uma aula de filosofia eheheh
Enfim, se imaginarmos que num projeto de milhares de classes poderemos evitar uma instanciaçao e poucar memoria e GC ter que ser acionado, pq isso nao seria bem vindo as vezes! Imagina a economia que teriamos
A unica dúvida que fico: O Refactoring utiliza o mesmo processo de carga que um static ?
saudaçoes
|
|
|
|
thingol wrote:
Então que tal fazer alguns "benchmarks" e ver qual é a diferença de tempo entre usar "static" ou não?
Já vou antecipando que a diferença é desprezível na maior parte dos casos de uso, mas não tomem minha palavra por verdade absoluta.
Thingol,
Estou partindo por lógica que 1 passo e mais rápido que 2...
Ai e so a questao de averiguar o quanto mais rápido, mas a lógica sempre vem antes de testar e programar..
Quem nunca ouviu de "tentiva e erro na programaçao", ai quem sofre é o compilador! rs...
:roll:
|
|
|
|
Bruno Laturner wrote:
E quem vir essa frase acima e for usar static pra tudo, e digo parabéns. Parabéns por ferrar com toda a arquitetura do teu projeto p/ ganhar alguns microsegundos. Ou parabéns por usar uma arquitetura totalmente procedural numa linguagem orientada a objetos, e ignorar todos os outros recursos úteis da linguagem.
Bruno,
Acredito que a razao aqui nao e provar nada para ninguem dizendo vc esta certo ou errado, e apenas buscar uma melhor soluçao num momento critico...
No mundo de TI, existem momentos em que termos a melhor arquitetura e a melhor saida.. mas como digo, existem outros momentos em que queremos somente perfomance ao limite!!
Ai nao adianta botarmos patterns, patterns, pq o que vai deixar rapido de verdade é o código simples ao extremo e quanto mais estruturado melhor! Como um profissional de TI posso lhe garantir!
Mas a grande enquente aqui foi, so se um static era mais rápido num metodo, e como podemos concluir isso é verdade! Depois de muita polemica e contradiçao no forum GUJ.
Se pensarmos isso é bonito? Talvez nao, mas se olharmos de outro angulo as vezes e a melhor soluçao, so cabe a vc decidir quando fugir ao extremo.
|
|
|
|