| Autor |
Mensagem |
|
|
É possível configurar o Maven para não ficar consultando os repositorios toda vez que eu executar algum goal?
É irritante isso, e quando minha internet está com algum problema isso acaba detonando minha produtividade.
Sei que tem o parâmetro "-o", mas isso faz com que o Maven deixe de baixar automaticamente as dependencias inexistentes.
Não dá pra configura-lo para tentar acessar os repositorios APENAS quando estiver faltando alguma dependência?
|
 |
|
|
Eu prefiro evitar essas bibliotecas como GXT, SmartGWT, etc. É tentador quando você compara o conjunto de widgets delas com os widgets padrão do GWT, mas ainda assim evito.
Principalmente aquelas que são apenas um wrapper para uma biblioteca em Javascript, pois assim eu perco todas as vantagens que o compilador Java/Javascript do GWT dá.
Outro problema é elas não se dão bem com widgets padrão do GWT, o que te deixa preso nelas.
E o GXT me parece que nem é compatível com o UiBinder, então é mais um fator contra o seu uso.
Sobre o UiBinder, o GWT Designer da Instantiations não o suporta (até onde eu sei). Segundo eles, o editor é um editor visual, não editor XML. Essa desculpa não faz o menor sentido pra mim, mas fazer o que.... Só espero que agora a Google implemente suporte ao UiBinder no plugin, por que senão a coisa toda ficaria um tanto quanto incoerente.
Mas de qualquer forma, nada disso serve pra mim, eu uso Netbeans 
|
|
|
|
Era o id zerado mesmo.
Por uma falha minha, este campo estava vindo zerado quando o objeto era transmitido do cliente para o servidor de aplicação
Obrigado
|
|
|
|
Estou desenvolvendo uma aplicação para rodar no Google App Engine que utiliza JDO para persistencia.
Consigo fazer consultas e inserções normalmente, mas ao tentar atualizar uma entidade, o JDO grava um novo registro, como se eu fizesse uma inserção.
Segue o código:
Um detalhe: A instancia de Customer que eu passo para o método saveCustomer() não é obtida pelo JDO. Ela é recebida através de uma chamada remota feita pelo mecanismo de RPC do GWT.
O que posso estar fazendo de errado?
|
|
|
|
Como já falei, tambem prefiro injeção pelo construtor.
Se um objeto MyDao PRECISA de um objeto Connection pra funcionar, não tem por que essa dependencia não ser passada no construtor.
Quando está escrevendo testes de unidade, é muito facil esquecer de chamar um setter para colocar uma dependencia. Já se for no construtor, você nem conseguiria compilar o código.
Ou então se esquecer de configurar a dependencia no container, ele vai simplesmente te entregar o objeto em um estado inconsistente. Se fosse no construtor, o container não conseguiria instanciar o objeto e iria ocorrer uma exceção
|
|
|
|
Pelo que eu entendi, você considera que em DI o container instancia a classe e retorna para você, mas sem considerar as dependencias da mesma.
Já no wiring, o container instancia a classe e ainda provê todas as dependencias que ela pode precisar.
É isso?
Se sim, então acho que não faz sentido chamar de DI. O container não injeta nada, só cria e retorna para alguem (e esse alguem sim, poderá injetar em algum lugar). No Emballo (o projeto que citei), faço esse wiring via construtor sem problemas. No GIN (Google Guice adaptado para o GWT) idem.
Se eu lhe entendi errado, peço que desconsidere o paragrafo acima
|
|
|
|
O que seria o wiring a que você se refere? Seria outro termo para injeção?
|
|
|
|
Algum motivo em especial para preferir via setter?
Digo isso por que eu implementei um container de DI para Delphi onde suporto apenas injeção pelo construtor (o projeto é novo... eventualmente posso implementar isso), e queria saber quais as vantagens de fazer injeção pelo setter.
Inicialmente eu suportava injeção diretamente nos campos do objeto (ou seja, sem passar pelo construtor nem pelos setters), mas depois descartei isso pois vi que era furada trabalhar assim
|
|
|
|
|
Não faz DI pelo construtor?
|
|
|
|
É... eu concordo com você. Mas me veio uma dúvida: se eu tiver clinetes que usam Bematech, outros Daruma, outros Elgin e outros Sweda, eu teria que escrever uma implementação específica pra cada impressora (se eu não utilizar a dll fornecida pela fabricante)?
Como já disseram, com ou sem dll vc tem que ter uma implementação específica para cada fabricante (e eventualmente você tem que dar tratamentos especificos para modelos diferentes do mesmo fabricante).
Ainda não trabalhei com Sweda, mas a Daruma é muito semelhante à Bematech. Não dá pra usar a mesma implementação nas duas, mas dá pra usar uma como base para a outra. Na verdade, até rola um processo da Bematech contra a Daruma acusando-a de ter copiado a biblioteca
|
|
|
|
Sinceramente não vejo vantagem em fazer comunicação direta... A não ser que que a fabricante da impressora não forneça a biblioteca para a plataforma desejada (Só a título de informação, a Bematech possui uma versão da biblioteca de acesso para Linux).
Falaram sobre ter controle total. Pra que? Se eu quero abrir um cupom fiscal, eu só quero um comando que faça a abertura do cupom fiscal e retorne algo dizendo se houve alguma falha. De que adianta eu implementar isso manualmente tendo controle total, se no final das contas eu vou ter um cupom fiscal igualzinho?
As bibliotecas de acesso tem funções para fazer o download da MFD e gerar alguns arquivos exigidos pelo PAF-ECF. Vai implementar isso na mão pra ver que beleza, não sei nem se é possivel (acho que essa parte não é documentada)
|
|
|
|
O problema que eu vejo no singleton é justamente o famoso 'getInstance()'.
Acho que fica muito menos problematico se o objeto cliente recebe o singleton por injeção de dependências, nesse caso o cliente nem precisa saber que aquela classe é um singleton. E se você usar algum conteiner de DI, esse controle pode ficar por conta do container
|
|
|
|
Voce pode usar DAO apenas, mas faca ele se passar por um repositorio para os objetos de dominio.
Tá, mas na prática, o que diferencia um repositório de um DAO, além do fato de um ficar na camada de domínio e o outro ser infraestrutura?
O que pode ser feito em um repositório que não pode ser feito em um DAO?
|
|
|
|
|
Nesse caso, o que é que os repositórios acrescentam ao sistema para justificar o seu uso? Por que não usar DAOs apenas?
|
|
|
|
Regras de negocio são coisas como "duas pessoas não podem reservar o mesmo quarto simultaneamente", como eu forço isto ? Com queris ? Não. Com validadores.
(...)
Portanto, repositorios podem ter regras de negocio ? Não. Repositorios existem para encontrar coisas, fazer (boas) perguntas. Não para decidir, impedir, proibir, controlar....
Agora, significa isso que repositorios ignoram o negocio ? Não. Eles sabem exactamente de que tipo de assunto estamos falando e o valor da pergunta que fazem.
Então não existem validações diretamente nos repositórios. Ao invés disso, os repositórios passam a bola para outra classe para fazer as validações antes de salvar as informações. É isso?
|
|
|
|