| Autor |
Mensagem |
|
|
Não precise colocar o 100 como double.
double a = 25;
double b = a / 100;
System.out.println(b);
0.25
O que não pode é usar dois inteiros e esperar um double.
|
 |
|
|
Pq vc esta divivindo int neh, tenta assim "new Double(25) / new Double(100)", ai vai dar certo.
|
|
|
|
|
Se não entrar no case, não vai acumular.
|
|
|
|
Imagine que acm1 = 0
porc1 = ((0 * acmtodos) / 100);
porc1 sempre vai dar zero.
|
|
|
|
|
Cola o código aqui.
|
|
|
|
Paulo Silveira wrote:oi pessoal
(in)felizmente ja lotou logo no primeiro dia. informaremos sobre as aulas abertas de temas de arquitetura em breve.
paulo
Olá Paulo, teria como filmar e disponibilizar as palestras?
|
|
|
|
|
Não separa seus objetos de negócio em classes de atributo e classes de negócio, valorize a orientação a objetos. Evite o modelo anêmico. http://martinfowler.com/bliki/AnemicDomainModel.html
|
|
|
|
Galera, é o seguinte tenho um cenário que envolve um estrutura de sistema WEB + EJB, e necessito dentro dos meus metodos nos EJB's, de um objeto que terei que colocar em algum tipo de "sessão" para que eu possa recuperar esse objeto nos meus EJB's, pois os resultados de processamento das minhas regras dependem desse objeto. Seria uma espécie de SessionContext, porém não irei guardar o usuario logado ou suas roles como o SessionContext já faz com o JAAS, esse objeto é mais complexo. Gostaria de sugestões arquiteturais para tratar este caso, pensei em algumas porém não gostei de nenhuma.
1. Manter a estrutura e mandar o objeto como parâmetro;
2. Manter a estrutura, colocar em um Stateful Session Bean meu objeto e mandar a referência por parâmetro;
3. Guardar em uma base de dados.
Os dois primeiros pontos, acredito que geraria overhead e não ficaria tão legal eu ficar trafegando isso junto com meus objetos de negócio, e o terceiro acredito que não ficaria tão legal eu ficar acessando base toda hora, seria melhor manter em memória.
Alguem tem alguma sugestão?
|
|
|
|
|
Não sei aonde vc viu a vantagem desse get e set, isso só favoreceu a modelo de domínio anemico (http://martinfowler.com/bliki/AnemicDomainModel.html), onde seus objetos ao invés de terem comportamentos que manipulam seu estado e que refletem a realidade do domínio, eles tem get e set e outras classes que manipulam seu estado, já tenho birra do get e set automatico que as IDE's disponibilizam, imagine isso rs.
|
|
|
|
Giulliano wrote:
tnaires wrote:Giulliano, a questão da imutabilidade colocada por você é relevante. Mas quanto à obrigatoriedade de getters e setters, é preciso lembrar que o Hibernate/JPA não a exige, desde que os atributos da entidade sejam anotados ao invés dos getters.
Quando eu disse que o JPA requer getters e setters não estava me referindo às anotações e sim ao modo o qual o framework obtem os valores do objeto. Se vc tem uma entidade com dois atributos privados como eu faço para acessar seus valores atráves de outro objeto ???
Pra isso serve o get e set. Metaprogramação e Relection.
Se o framework que vc esta falando é o Hibernate, realmente não precisa de get e set, ele vai por reflection, então com relação a persistência, não teria problema não termos o get e set, já na parte web, ai sim temos problemas, que a maioria do framework web, segue este padrão "burro" de get e set.
|
|
|
|
Isso é um assunto tb que já vi vários arquitetos e projetistas tratarem de formas diferentes, mais o que mais vejo é a seguinte estrutura:
Módulos: Utilizando como agrupamento de funcionalidades como por exemplo (Financeiro (web, api, core, domain), estoque (web, api, core, domain), venda (web, api, core, domain));
Pacotes: Entram dentro dos módulos para separação de meio que responsabilidades tb, mais dentro do contexto global de um módulo exemplo (dentro do financeiro, teremos os pacotes de entidades, talvez criteria, utils, vo);
Vejo tb a divisão dos módulos pensando em camadas(Layers) por exemplo, WEB (Financeiro-web, Estoque-web, etc), CORE (Façades e services. Ex. Finaceiro-core), API (Interfaces de serviços. Ex. Financeiro-api etc), DOMAIN (Dominio da aplicação. Ex. Financeiro-domain, etc).
Vejo bastante isso integrado com o Maven por exemplo, e ai com relação a chamada indiscriminada de funcionalidade entre os módulos, causa por consequência dependência cíclica, fazendo com que os módulos tenham de ser bem estruturado e independentes, senão é uma boa idéia ver a possibilidade de unilos.
Já vi de várias formas, e nunca vi nenhum artigo técnico dizendo a melhor forma de se fazer isso mesmo, acho que parte mais da estratégia adotada pelo arquiteto ou projetista, ou seja lá quem for.
Até mais.
|
|
|
|
javamaniaco wrote:
analyser wrote:
djemacao wrote:Ok Sergio, façamos o seguinte, me passe o nome dos livros que leu, já que o que menciona é não aceitar layer para cada parte de MVC, agora me prove porque. Citei o blueprints, agora é sua vez de citar bons livros já que acha que não li os bons. Me desculpe, mas sua capacidade de convencimento é fraca porque mostra explicações, até muito boas, mas as fontes que são mais necessárias ainda não vi. Fora que sempre cita o Java, não conheci o DDD só no Java, conheci no .Net também. Não paro de chamar de layer porque são assim nos livros. Não dá pra ficar chamando de andar. Desculpe se estou lhe irritando, mas sou chato mesmo  .
O problema é exatamente esse, vários livros estão errados sobre seus conceitos, pq? Pq leram outros livros errados, e assim por diante, é um conceito muito difícil de corrigir, é como uma bola de neve, um explica o conceito errado e assim vai, partindo pelos péssimos professores universitários que temos, não quero generalizar, existem ótimos professores e eu conheço sim, mas também existem outros que não aplicam o conceito certo, e a aprovação desta monografia apresentada neste post, é uma prova disso. []s
Desculpe ai os dois que ficaram discutindo é ou não layer, mas sinceramente, não ganhei nada com essa discussão
Amigo, nem todas as discussões e comentários agregam algo de valor, por exemplo seu comentário num agregou em nada tb a discussão.
Eu só sei que estão dificultando demais o que seria simples, só isso.
Exato, esse é o problema.
To começando a realmente achar que Ruby on Rails é onde devo pousar e mudar meu nick pra rubymaniaco  .
Acho que a discussão se volta para o conceito de MVC e Camadas, e não para a linguagem java em específico, mais tai fiquei com uma dúvida agora que vc pode me esclarecer, o conceito de MVC e Camadas no ruby é diferente?
|
|
|
|
djemacao wrote:Ok Sergio, façamos o seguinte, me passe o nome dos livros que leu, já que o que menciona é não aceitar layer para cada parte de MVC, agora me prove porque. Citei o blueprints, agora é sua vez de citar bons livros já que acha que não li os bons.
Me desculpe, mas sua capacidade de convencimento é fraca porque mostra explicações, até muito boas, mas as fontes que são mais necessárias ainda não vi. Fora que sempre cita o Java, não conheci o DDD só no Java, conheci no .Net também.
Não paro de chamar de layer porque são assim nos livros. Não dá pra ficar chamando de andar. Desculpe se estou lhe irritando, mas sou chato mesmo .
O problema é exatamente esse, vários livros estão errados sobre seus conceitos, pq? Pq leram outros livros errados, e assim por diante, é um conceito muito difícil de corrigir, é como uma bola de neve, um explica o conceito errado e assim vai, partindo pelos péssimos professores universitários que temos, não quero generalizar, existem ótimos professores e eu conheço sim, mas também existem outros que não aplicam o conceito certo, e a aprovação desta monografia apresentada neste post, é uma prova disso.
[]s
|
|
|
|
djemacao wrote:
analyser wrote:Como foi muito bem falado pelo "Shoes", Camada e MVC são diferentes, tenham isso na cabeça, e Camada tb difere entre "Tier" e "Layer", uma coisa que acaba de vez com a confusão de camada e MVC é simples, eu posso ter MVC em apenas UMA camada, pronto, a partir disso esta claro que MVC é diferente de CAMADAS. Sugiro ler o artigo do Shoes citado neste post (fragmental) e ler novamente a reposta do Sergio Taborda.
Um problema destes conceitos é o seguinte, a maioria tem o conceito errado sobre MVC e Camadas, então como a maioria explica errado acabamos achando que a minoria que explica certo esta errada.
[]s
Camada ou não camada? Layer ou tier? Bom, vamos aos fatos. Falando de Java? Leiam o BluePrints:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch2.html
Podemos SIM, dizer que cada parte do MVC é uma camada (layer), ou traduz de outra forma agora?
Concordo bastante com o que vc diz, e todas as discuções se voltam na maioria das vezes a traduções e interpretações diferentes, quando disse que pode ter MVC em uma camada só, me referia a Tier por exemplo, e não fui muito bem claro, agora não concordo com cada parte de um MVC pode ser uma Layer, não vejo um sistema real que divida em duas layers por exemplo View e Controller, se considerarmos por exemplo o básico "Apresentação/Aplicação/Negócio/Persistência", ou seus derivados, enfim não vejo essa seraparação de MVC sendo cada parte uma camada, mesmo se tratando de layers.
|
|
|
|
Como foi muito bem falado pelo "Shoes", Camada e MVC são diferentes, tenham isso na cabeça, e Camada tb difere entre "Tier" e "Layer", uma coisa que acaba de vez com a confusão de camada e MVC é simples, eu posso ter MVC em apenas UMA camada, pronto, a partir disso esta claro que MVC é diferente de CAMADAS. Sugiro ler o artigo do Shoes citado neste post (fragmental) e ler novamente a reposta do Sergio Taborda.
Um problema destes conceitos é o seguinte, a maioria tem o conceito errado sobre MVC e Camadas, então como a maioria explica errado acabamos achando que a minoria que explica certo esta errada.
[]s
|
|
|
|
|
|