| Autor |
Mensagem |
|
|
|
Vlw! Vou dar uma pesquisada...
|
 |
|
|
Bom dia,
Tendo uma tabela, por exemplo:
----------------------------------------------------------------------------------
| DATA | BYTES_ENVIADOS | BYTES_RECEBIDOS | TELEFONE |
----------------------------------------------------------------------------------
2011-03-01 | 1200 | 545 | 1191545454 |
----------------------------------------------------------------------------------
Problema 1:
Tendo que agrupar por DDD's, sem poder criar uma coluna DDD e populá-la, o correto seria fazer um GROUP BY no campo telefone, utilizando substring, e criando um index nesta coluna, ok?
Porém, essa tabela contém uma quantidade absurda de dados. Haveria uma melhor solução?
Problema 2:
Devendo haver opção de agrupamento por UF (estado), para uma consulta nesta tabela, uma segunda tabela seria criada, com os campos DDD e UF, e mais uma vez, a ligação seria feita utilizando o campo telefone, também através de uma substring, em um join...
A pergunta é: Como lidar com esta situação, de uma maneira mais eficiente, em termos de performance?
Agradeço a atenção!
|
 |
|
|
Boa noite.
Gostaria de saber se alguém conhece alguma API que dê suporte a arquivos .swf, de modo que eu possa, após fazer o upload de um arquivo desse tipo, verificar, por exemplo, qual é a altura e largura do arquivo (width & height), assim como podemos fazer com imagens (ex.: java.awt.image.BufferedImage - http://codemate.wordpress.com/2009/05/07/image-manipulation-in-java/).
Obrigado!
|
 |
|
|
Naquele jeito que eu passei alí em cima, não. Ele só sabe que , de acordo com o input, ele vai retornar uma factory diferente. Acontece que esse input vem do controller, que vem da view... ou seja, vai mudando. Se por acaso a view acrescentar mais valores, por exemplo, é só acrescentar uma entrada no map.
Se eu consegui entender a necessidade do padrão Abstract Factory, acredito que esta explicação é bem válida, pois, deixa mais "genérico". Certo?
|
 |
|
|
Está quase lá... o seu método getInstance() está meio "complicado", porque se o cliente sabe que Usuário quer, como nessa linha:
Tem toda a razão... realmente fugiu da idéia da utilização do padrão... Curti a idéia de passar o input, massa mesmo!
Substitua getCpf() por getDocumento
Ótima alternativa tbm! Valew pela ajuda de todos!
|
 |
|
|
Olá a todos,
Já existem vários tópicos sobre esse padrão de projeto, eu sei, mas minha dúvida é um pouco mais específica.
Bom, primeiro vai o código.
Tenho assim o meu Abstract Factory:
Bom, primeiro, como existem aqui vários experts no assunto, gostaria de saber se consegui assimilar o padrão, segundo, e principal, diz respeito a utilizaçao por parte do cliente:
É correto o método "create()" retornar a classe abstrata (Usuario)? Acho estranho, pois, assim teria que fazer um cast toda hora, até pq UsuarioFisico tem o método getCpf(), no qual não existe, obviamente no UsuarioJuridico...
Opinem, por favor...
Obrigado!
|
 |
|
|
Olá a todos,
Tenho em meu projeto um service (SubcategoriaService), no qual criei para obter listas de Subcategorias, Categorias-pai das Subcategorias, etc..
Não criei um repository pois creio que (me corrijam por favor se eu estiver errado...) minha classe Subcategoria, no contexto atual, não se trata de uma Aggregate Root..
Bem, a duvida maior na verdade é se é correto (ou recomendado, elegante, etc...) fazer algo assim:
Método da classe SubcategoriaService:
Ou seja, é elegante passar uma query por aqui? Onde Repository é um Repository Genérico, no caso.
Valeu pela força!!!
|
 |
|
|
Boa Tarso! Uma pergunta, A implementação do UsuarioRepository seria um DAO?: EXEMPLO: abraço!
|
 |
|
|
O que acham disso? Sejam sinceros. E pacientes (não sou experiente, tô afim de aprender, e tem gente que costuma socar a coisa hehehe...) Eu poderia ter (claro que poderia, mas digo, é correto?) o procedimento existente no ControladorDeAcesso, diretamente no Usuario? Digo, posso instanciar um DAO diretamente no Usuario?
|
 |
|
|
|
Bacana! Valeu colega!
|
 |
|
|
Numa Entidade o identificador é um dos atributos do objeto e que por si só representa sua singularidade no domínio, ou falando mais fácil, o identifica. Portanto duas instancias com mesmo atributo são considerada iguais.
Ok, então não é o conjunto de TODOS os atributos, mas sim algum atributo em comum que o faz diferente dos outros (Entity)? E isso independe de como eu trate em questão de persistencia? Ou seja, mesmo que eu não anote o atributo url com um @Id, mas crie um campo id para tanto? Posso definir que, se todos os atributos (juntos) de um objeto, formam sua singularidade, é VO. Se nenhum dos atributos o faz, necessitando então de um campo identificador, ou mesmo se um (ou mais) satisfaz essa singularidade, é Entity?
|
 |
|
|
ok, vamos lá... pra ver se eu estou conseguindo entender: Um objeto Menu, com os atributos id (por causa do BD), nome, descricao, imagem, url. Tenho duas instâncias, com o mesmo nome, descrição, imagem e url. Digo que as duas instâncias representam o mesmo Menu, pois em meu contexto, não faz sentido dois menus apontando para o mesmo local... Tenho então, neste caso, uma Entidade, certo? Pois a url garante que o Menu seja único. Posso ter duas instâncias de um objeto, com TODOS os atributos iguais e essas instâncias estarem representando indivíduos distintos? SIM = esse objeto é um Entity. NÃO = trata-se de um VO. Pode-se perguntar de outra maneira: Posso ter dois objetos (ou mais) cadastrados no sistema (BD) com todos os atributos iguais? SIM = Deverá ser um entity. NÃO = Deverá ser um VO. Certo ou errado?
|
 |
|
|
|
ok, então esse ItemDePedido faz parte do aggregate onde o root é Pedido, e não é nem VO nem Entity? Eu pensava que em um modelo de domínio só teríamos esses dois tipos de objeto...
|
 |
|
|
Gente, muito obrigado a todos, este tópico está sendo muito construtivo pra mim! Seguinte, usando o hibernate tools e fazendo engenharia reversa, quando temos alguma tabela com chave composta, automaticamente a ferramenta gera duas classes, uma (ID) que acredito ser um VO. Exemplo: Neste exemplo, ItemDePedido representa uma tabela m:n e ItemDePedidoId representa sua chave. ItemDePedido é um VO (nítidamente), e ItemDePedido, é mesmo uma entidade, mesmo sabendo que seus valores (que no caso é sua chave) nunca se repetirão? E mochuara, então se não é @Embeddable, quer dizer que não é um VO? Editado: Outra coisa, quando se trata de um VO, então se "olha" para os valores, desprezando sua chave, correto? Acontece que se eu instanciar um novo objeto, com os valores de um objeto que já exista (i.e. UF), e desprezar o valor da chave, este seria um novo objeto, acontecendo diversas replicações toda vez que eu precisar de um objeto desse... Tudo bem, daí vc pode pensar, mas se o Id do UF é a sigla, é só setar a sigla que eu já sei qual o valor do nome do estado, por exemplo. Mas então ainda assim este objeto é uma Entidade, pois a sigla funcionaria como um CPF.. ou não? Isso que eu não entendo... valew!
|
 |
|
|
Não não...
A questão é a seguinte, eu entendi bem nos exemplos mais triviais, como Endereço, que não se trata de uma tabela no banco (Desculpe, ainda não consegui fazer o tal do "Database não existe..."). O problema é com os VOs que são uma tabela e possuem chave...
No exemplo citado, UF, a sigla sendo sua @Id (também ainda me sinto preso ao ORM...), já não caracteriza sua identidade? Pois, não existem dois Estados com a mesma sigla...
outra dúvida é, como obter uma lista de todos os VOs Estado, uma vez que VO não possui repository?
Desculpe se não estou conseguindo ser muito claro...
Obrigado pela ajuda, Tarso!
|
 |
|
|
|
|