Galera eu gostaria de saber exatamente onde é aplicado as collections, os beans num projeto java?
E vcs sabem algum site com exeplos de interfaces para sistemas não sites web
Rocha
Talvez todas as camadas do seu sistema trabalhem com collections ou beans…Depende de como vc o projetou.
É exatamente isso q quero saber, devo usar isso? porque? onde?
Rocha
explicação rapida:
bean é normalmente uma classe com atributos e metodos get/set para elas.
podem representar entidades de um banco de dados ou agrupar informações.
podem ser usados para transporte de dados entre as camadas.
collections é um conjunto de interfaces/classes que servem para criar conjuntos de objetos, e possuem varias implementações diferentes, uma para cada fim especifico.
vc pode ter coleções que funconem como fila, pilha, lista encadeada e varias outras.
quando vc precisa de um conjunto de beans por exemplo, vc pode usar uma collection para isso.
de uma olhada na api, é leitura basica para qualquer desenvolvedor java.
[]'s
Bom, collections em todo lugar que você precise de um estrutura de dados para guardas vários objetos, isso acontece em todas camadas da aplicação.
Beans, vc precisa somente se tiver programando com o modelo de JavaBeans ou ferramentas que usam sua notação (são MUITAS), senão pode jogar fora todos esses getter/setters atoa.
Mas louds, como utilizaria meus Domain Objects sem setters/getters???
Eu já havia visto esse tópico, mas ainda não tive tempo suficiente de lê-lo com tanto carinho assim, bem como os artigos citados. Infelizmente…
A questão é que para operações de persistencia vejo uma mudança realmente significativa, e os modelos mostrados são bem intuitívos…
Mas e com relação a exibição do estado de meus objetos, por exemplo, pela view? Como ficaria se não definisse os meus setters e getters??
Leia o segundo artido indicado pelo AllMighty.
Resumindo: se o campo Nome precisa saber o Nome da Pessoa e a Pessoa precisa saber o valor do campo Nome, por que diabos colocá-los em lugares diferentes? O autor sugere uma implementação que achei bastante elegante, sem ferir a separação de camadas.
Nela, objeto Pessoa sabe que tipo de componente representa seus atributos, mas não precisa ter a menor idéia de onde ele será mostrado, com que disposição nem o que vão fazer com ele.
Depois de ler o artigo fiquei com um nojo danado do input precisar ter o mesmo nome do getter na classe, senão nada funciona. Convenhamos, isso é nojento