| Autor |
Mensagem |
|
|
É verdade. Apenas não é verdade que "ioc é o conceito que define frameworks". Para fazer IOC não precisa de frameworks.
Concordo que para usar IoC não precisa de um framework. Mas o que eu quis dizer com "ioc é o conceito que define frameworks" é que o uso de IoC é o que diferencia um framework de uma biblioteca de classes.
|
 |
|
|
Na verdade inversão de controle (ioc - inversion of control) é um conceito que engloba injeção de dependencias (di - dependency injection), mas é bem mais abrantente.
ioc é o conceito que define frameworks, e significa que o framework chama o seu código (e não o contrario).
Por exemplo, quando colocamos um listener em um componente swing, isso é ioc, mas nao tem nada a ver com di
|
|
|
|
Dificuldade para testar é um bom indício de design ruim.
Se estes métodos privados são tão importantes e tão complexos, talvez eles deveriam estar em outras classes. Defina interfaces para abstrair essas classes e use injeção de dependencias para coloca-las no seu objeto.
E você pode sugerir à sua empresa rever essa política de 100% de cobertura. 100% de cobertura não significa que o sistema está livre de bugs.
|
|
|
|
Putz, não vai ter properties? 
|
|
|
|
Consegui resolver.....
Não havia configurado o parametro java_home nas configurações do Hudson
|
|
|
|
Muito obrigado, Don, mas consegui encontrar isso no proprio Maven. Basta configurar o plugin de geração de war como segue:
Não me agrada usar a versão beta do plugin, mas com as anteriores esse recurso não funcionou corretamente.
|
|
|
|
Concordo que ele precise... Mas os jars que acompanham minha aplicação, acho que não precisam estar com o número da versão...
No meu caso, isto está me atrapalhando especificamente pra importar as tags do Mentawai para usar nos meus jsp. Do jeito que está hoje, eu preciso colocar a versão do mentawai nos jsp todos. Aí se um dia eu precisar usar uma versão diferente, vou ter que sair alterando todos os jsp. E não acho isso uma boa.
|
|
|
|
Há uma forma de personalizar o nome do jar de alguma dependencia que vai para a pasta lib?
O maven por padrão está usando <artefactId>-<version>.jar, mas eu queria suprimir a versão...
|
|
|
|
|
Ah sim, só pra acrescentar, se eu chamar o maven diretamente, está funcionando. Tanto na minha máquina quanto na máquina onde está o Hudson
|
|
|
|
Estou tentando configurar o Hudson para integração contínua.
Quando mando construir o projeto, ocorre esse erro:
Estou usando o Hudson 1.321 rodando num Tomcat 6.0.20 e Windows XP.
O projeto usa Maven 2.2.1
Alguem sabe o que falta configurar?
|
|
|
|
Estava aqui pensando...
Muito vejo falar sobre DAO com Hibernate, aí me veio uma dúvida:
O próprio Hibernate pode ser considerado uma implementação de DAO? O que é um DAO se não um mecanismo para abstrair o mecanismo de persistencia dos objetos? E o Hibernate idem, não? A diferença é que o DAO pode ser implementado para operar em cima arquivos XML ou o que quer que seja, enquanto o Hibernate é mais voltado para um RDBMS.
Digo, considerando que um sistema só vai acessar dados provenientes de um banco de dados relacional, há mesmo a necessidade, na opinião de vocês, de encapsular o Hibernate em um DAO?
Eu, particularmente, não estou conseguindo enxergar tal necessidade.
Teoricamente, eu automaticamente já teria um DAO para Firebird, MySql, HSQL, Oracle, etc, apenas configurando o Hibernate apropriadamente...
|
|
|
|
Estou desenvolvendo uma aplicação web usando Mentawai...
Preciso escrever testes para uma Action que possui alguns atributos privados que são instancias dos meus repositorios...
ex:
Em produção, posso usar o recurso de injeção de dependencias do menta para instanciar o repositorio e colocar na minha variável de instancia clienteRepositorio.
Mas em ambiente de testes, preciso colocar ali um "mock" do repositório. Pensei em em aumentar a visibilidade da variável (package ou protected), e no teste eu coloco algo ali manualmente... Ex:
Aí vem minha dúvida: Eu faria essa mudança meramente para viabilizar os testes. Isso deveria ser evitado, na opinião de vcs?
Recomendam alguma outra alternativa?
|
|
|
|
|
Qual a diferença entre Conta e ContaBLL?
|
|
|
|
Vejo muito isso em Delphi... T como prefixo para classes, records e enums, I para interfaces, F para variáveis de instancia.. Eu particularmente não gosto nem um pouco, e felizmente em Java normalmente não vejo nada disso, exceto o já citado "able", mas esse sufixo é até bem natural.. tipo:
public class Client implements Serializable, Cloneable -> Serializavel, Clonavel. Na verdade ficaria até menos natural sem o sufixo...
|
|
|
|
Tenho a seguinte situação aqui:
Uma abstrata classe que chamarei de Base, e que atualmente possui duas subclasses: SubclasseA e SubclasseB
Tenho um método que recebe um argumento do tipo Base e, dependendo do tipo real da instancia (SubclasseA ou SubclasseB), precisa criar um outro objeto.
A princípio seria algo assim:
Mas isso violaria o chamado "princípio aberto/fechado" (o nome em inglês soa melhor, mas vá lá...), estou correto? Pois se um dia eu criar uma nova subclasse de Base, teria que voltar aqui e alterar este método...
Acham que devo me importar com isso? É bem improvavel que surja uma outra subclasse aí....
Não dá para deixar isso em um método abstrato em Base pois Base seria uma classe de negócio e ali preciso instanciar uma tela (view) para manipular este objeto.
Um factory, seria apropriado?
De que outra forma vcs fariam isso? Estou seguindo algum caminho errado?
|
|
|
|