Mais lenha na fogueira dos entity beans...

http://www.manageability.org/blog/stuff/scalable_ejb_idiom

The most scalable idiom is the one that uses zero (i.e. none, zippo, zilch) Entity Beans.

Novidade pra muitos aqui, acredito... :o

Ae cv blz?
Bom nao basta criticar neh... Fala ae quais são suas alternativas para persistencia de dados fora Entity Beans...
Ae a galera pode ter uma base mais legal pra escolher se usa ou nao entity beans.

PS: fiz um build.xml e um xdoclet q ficou bem legal depois postarei e gostaria de criticas suas e do ozie, q parecem ser as pessoas q mais conhecem a tecnologia aki....
Qualquer outra pessoa q conheca bem tb , gostaria de ouvi-lo ...

Abraços a todos

Opções para persistência não faltam. E o melhor, estas opções não precisam de um trambolho como um servidor J2EE acoplado para funcionarem. As opções vão desde o bom e velho JDBC, passando por frameworks de persistência como o Hibernate (meu favorito!), JDO, OJB, Torque, Prevayler (este sem usar banco de dados), chegando até o pouco conhecido JavaSpaces, que faz parte da tecnologia Jini. Esta última opção pode ser muito útil caso você precise de espaços persistentes distruídos E transacionais.
E, como disse antes, você pode usar todas as alternativas onde você quiser: em uma aplicação Swing de duas camadas, em uma aplicação de WEB que não precisa de muita frescuras ou em uma aplicação J2EE completa, substituindo aquele lixo dos entities.

por falar em JavaSpaces,
alguem ja utilizou isto?? tem algum parecer??
existe alguma implementação free? (só ouvi falar de duas implementações comerciais

)

urubatan wrote:
existe alguma implementação free? (só ouvi falar de duas implementações comerciais )

RI da sun, nao?

Eu já usei. É uma visão diferente de persistência, na minha opinião. Mas não deixa de ser interessante. A idéia é que seja lá o que for colocado dentro de um Space não é nada mais do que mero dado, ou seja, se você enfiar um objeto em um destes espaços, você não vai poder invocar nenhum método dele. Para tanto, é preciso travá-lo (ou seja, ninguém acessa aquele objeto até você destravá-lo), obter uma cópia, invocar o método e depois recolocar a sua cópia de volta no espaço. Mas há uns problemas que poderiam ter sido resolvidos, mas não foram. O principal se refere a uma coisa muito feia: todas as propriedades de um objeto que vai ser inserido no espaço devem ser declarados como PÚBLICOS!!!

Mais ou menos assim:

Feio, né? Espero que eles tenha resolvido isso na versão 2.0 do Jini.
Ahhh outra coisa interessante de se lembrar: caso você queira, por exemplo, persistir uma lista de objetos, JAMAIS use arrays ou quaisquer collections. Lembre-se que, fazendo isso, ao travar o objeto para atualizar uma posição do seu (por exemplo) array, você vai travar o acesso ao objeto, o que não é muito interessante. Para isso, você tem que implementar uma "lista" no JavaSpace. Mais ou menos assim:

Desta forma, quando você precisar atualizar alguma posição da sua lista, você o faz procurando por um objeto no espaço cuja propriedade index seja igual àquela que você queira atualizar.

Bom, sobre implementações abertas e gratuitas, a próprioa implementaçào que vem junto com o Jini Starter Kit é gratuita. A IBM, se não me engano, também tem sua implementaçào de JavaSpaces, que se chama TSpaces (ou TupleSpaces, não lembro).

Maiores informações, no GOOGLE ou no JINI.ORG.

Até,

Notícias, artigos e o maior fórum brasileiro sobre Java