| Autor |
Mensagem |
|
|
Thiago Senna wrote:
Essa discussão não é muito pro meu bico
Não sou puxa-saco.
Cara eu acho que vc tem bagagem até de sobra para postar nesse tópico.
É lógico que tem especialistas como o Shoes e Cv em arquitetura mas sua ppinião é bem interessante.
|
 |
|
|
|
É verdade LIPE, até para migração de versão de uma hibernate para outro. E manter uma padrão entre os desenvolvedores do projeto.
|
|
|
|
Eu acho que colocar o hibernate em uma camada abaixo dos DAOs não é problema nenhum.
Achei bem legal os itens que o CV colocou, pois na prática temos que simplificar mesmo.
Mas abstrair é bom para ter reuso de código e facilitar implementações futuras. Fazer rafactory sempre dá trabalho, então tentar ter uma arquitetura que facilita de uma forma cada vez maior novas implementações e o reuso.
É lógico que como o CV falou: Ficar mais de 30 minutos para decidir em projeto a arquitetura de uma DAO é inviável.
Mas como estamos no GUJ é sempre bom discutir, é para isso que ele existe.
|
|
|
|
Gostaria de saber sobre experincias mesmo para ver se o negocio funciona.
O desempenho é bom ?
A compatibilidade é preservada ?
|
|
|
|
Alguem já usou o GNU Compiler for Java ?
Parece que ele além de compilar para Class ele compila para .EXE.
|
|
|
|
É verdade desculpa...
Fiquei com trauma do pessoal que estava criando new topic toda hora e fiquei com vergonha, mas na verdade foi ao contrário.
Se o moderador quiser fazer isso seria melhor.
|
|
|
|
Daniel tenho essa dúvida, como poderia resolver.
Para deixar as classes instanciadas pela factory fora do pacote dela eu teria que deixar o construtor public.
Mas ai eu poderia instanciar essas classes pelos clientes sem usar a factory.
|
|
|
|
O problema de criar classes via factory é que essas classes devem ficar no mesmo pacote do factory (ou não ?)
ex:
EDITADO:
Gostaria de aproveitar o tópico para tirar esta dúvida
|
|
|
|
Acho legal fazer um ActionClass por form.
Isso seria uma boa ideia ?
|
|
|
|
O hibernate parece ter um CustomPersister para vc controlar como será feito a persistencia.
Tem um exemplo com hashtable. Eu acho que ele faz o relacionamento automático das classes.
|
|
|
|
Gostei muito da padronização das telas.
|
|
|
|
É verdade, na prática mesmo tudo isso é o que vale.
Depois dessa até eu desisto...
|
|
|
|
Com o genérics: beleza.
Mas com o 1.4 criar uma interface de colecao seria interessante.
|
|
|
|
É verdade Maurício, generalizar nesses casos é bem melhor.
Estou entendendo agora a sua posição.
Mas uma coisa muito gernérica não tira a flexibilidade e os recursos type safe do java ?
ex:
Perco a checagem em tempo de compilação.
EDITADO:
Enquanto o List vai ai mais uma classe: De Colecao.
Idependencoia total
|
|
|
|
Na minha humilde opinião não é a questão de trocar, mas de clareza de código também e divisão de responsabilidades.
Vamos supor que vc tenha que no futuro implemntar um mecanismo de log toda vez que fizer uma inserção.
Separando as responsabilidades isso fica mais fácil de implementar.
Não dá para prever tudo (impossível). Mas tente prever pelo menos aquilo que sua experiência já lhe mostrou.
Os patterns foram feitos para serem usados, pois é o resultado da solução de problemas que foram enfrentados anteriormente por alguém.
Mesma coisa os frameworks.
Mas devem ser usados com coerencia e não por modismos.
Acho que desenvolver sua apliação para se moldar ao pattern é errado.
Mas usar sua apliação para usar o pattern é o correto.
|
|
|
|