Olá
Trabalho com ECLIPSE3.1, JBOSS, SERVLET, JSP, JDBC, DAO, e tenho um DAO com 4 methodos INCLUIRCLIENTE, ALTERARCLIENTE, EXCLUIRCLIENTE,CONSULTARCLIENTE, hoje esses methodo estão corretos, porem o meu chefe pediu para implementar EJB3.0 porque ele achou bonito, minha pergunta é muito simples como começaria a implementar esse(s) EJB(s) ?
Ou mesmo alguem estaria disposto a me ensinar a impementar pois acho que vai levar muito tempo até isso acontecer, alguem estaria disposto a fazer isso, tem eu e mais uma pessoa querendo aprender a implementar podemos negociar um preço.
eu utilizaria hibernate com ejb 3.0.
a funçao do hibernate é livrar do container ejb como jboss …
Voce pode usar a API de persistencia do ejb 3.0 em tomcat sem sequer precisar do hibernate.
fabriciobraga
O scottys tem razão.
Os entitys da especificação 3.0 não são mais serviços, e sim POJOS. Você poderia utiliza-los apenas com um Web container.
Se quiser aprender, tem alguns tutoriais por aí. Eu fiz um e disponibilizei no meu site, onde também tem alguns artigos falando da especificação EJB 3.0: http://www.fabriciobraga.com.br
como é feito as configurações de conexao com o banco???
como é feito a consulta/insersão/alteração dos dados ??
fabriciobraga
Phillip,
Com todo respeito pelo profissional bem conhecido que você é, mas permita-me discordar de você quando você diz:
Talvez a confusão esteja no fato de que o que eu chamei (grosseiramente) de “serviços”, na verdade são Business Objects.
Se for só essa a confusão, considere a discussão encerrada aqui, e eu assumo a culpa por ter utilizado a palavra erradamente. Se não for apenas isso, leia meus argumentos abaixo.
Meu postulado é: POJOS não são Business Objects.
Explicação curta:
O comportamento de um Bussiness Object não é apenas representação de dados, se for, ele não é um Business Object. Uma melhor definição para o comportamento de um Business Object seria dizer que ele precisa ter alguma lógica de negócio e/ou acessar outros Business Objects.
Perceba que na especificação EJB 2.1 o Entity se enquadra nessa opção, porque tinha sim, alguma lógica de negócio. Tanto que havia objetos separados para a representação dos dados (“Data”) e outro que era na verdade uma referência para uma instância do Entity (“Local”). O “Local” sim, era um Business Object.
Bom, serviços são serviços e business objects são business objects, logo sua afirmação não me pareceria coerente caso você utilizasse o termo ‘serviço’ no lugar deste. Eu posso ter serviços baseados em funções altamente procedurais e nenhum rastro de objetos, por exemplo.
De qualquer forma, vamos então substituir a palavra ‘serviço’ por business objects por correção, visto que não são diretamente equivalentes (um objeto de negócio provê serviços).
Lá embaixo você cola o link do Fowler que foi um dos criadores, como você citou. Vamos ver o que ele diz:
POJOs não são apenas ‘representação de dados’, logo anda impede que um POJO seja um objeto de negócio (aliás é altamente recomendado).
O que define um POJO é o fato dele não implementar nem estender classes de frameworks. Um Servlet não é um POJO, por exemplo, porque para criar um Servlet você precisa estender uma classe. Já o exemplo abaixo é um POJO:
classUsuario{
}
Mesmo estando vazia ou mesmo se eu implementasse métodos de negócio. Eu estenderia a definição apra dizer que POJOs só se relacionam com POJOs, ou seja: um POJO não dependeria de qualquer framework de infra-estrutura, mas esta última característica é uma definição pessoal minha.
Um Business object não precisa ser um POJO, um POJO não precisa ser um Business Object mas estes termos não são mutuamente exclusivos, muito pelo contrário é altamente recomendado que objetos de negócio sejam POJOs.
Você está dizendo que um Entity bean é um Business Object? Bom, em um conceito amplo pode até ser mas a ausência de um Domain Model num modelo EJB 2.x me faz ter uma certa aversão a esta classificação… enfim, acho que a coisa fica subjetiva neste nível.
Deixa disso rapaz, isto é um fórum
fabriciobraga
Mas essa discussão começou exatamente por eu dizer que não são! Caro Phillip, não ponha palavras na minha boca.
Aqui minha afirmação original:
O que eu tentei explicar e talvez não sido claro o suficiente, é que na especificação anterior (2.1) eles (os Entitys) eram Business Objects, mas na atual especificação (3.0) não são mais. São POJOS.
São representações de dados, pura e simples. Pelo menos para mim, este nossa debate gira em torno dos Entitys serem Business Objects (grosseiramente chamados de serviços na mensagem original) ou não.
Lembre-se de que o ponto inicial do qual eu discordei foi sua afirmação de que:
Na especificação EJB 3.0 os Sessions são Business Objects, os Entitys, não. Foi isso que eu afirmei, e você discordou, e depois eu discordei de você. Vamos nos ater ao que está sendo discutido.
Aqui a defnição do próprio site do JBoss:
The entity beans are designed to bridge the gap between the objects representation and relational representation of application data. From the Java developer’s view, EJB 3.0 entity beans are just plain old Java objects (POJOs) with annotations that specify how the object should be stored in the database. The mapping from the objects to relational database tables is done automatically and transparently by the EJB 3.0 container. The Java developer no longer needs to worry about the details of the database table schema, database connection management, and specific database access APIs.
Voce pode usar a API de persistencia do ejb 3.0 em tomcat sem sequer precisar do hibernate.
como é feito as configurações de conexao com o banco???
como é feito a consulta/insersão/alteração dos dados ??
usando apenas o tomcat?
pcalcado
Mas essa discussão começou exatamente por eu dizer que não são! Caro Phillip, não ponha palavras na minha boca.
Uh? Calma aí, eu não coloquei nada na sua boca. Eu perguntei, não afirmei, atenção ao ponto de interrogação.
O ponto é que eu acabei de entender sua confusão, creio. Quando Fowler fala sobre Entity beans ele fala sobre Entity Beans 2.x, não 3.0. São coisas muito diferentes.
fabriciobraga:
Aqui minha afirmação original:
Como falei, creio que você está confundido Entity Beans 2.x, 3.0, Session beans, POJOs e serviços.
Que tal esta afirmação sua?
Foi isso que eu comentei na minha resposta.
Por favor indique qual literatura afirma que POJOs não são Business Objects ou se esta definição é sua.
Por favor indique qual literatura afirma que POJOs são “representações de dados, pura e simples” ou se esta definição é sua.
Novamente, Fabrício: POJOs não são depósitos de dados burros e objetos de negócio devem ser POJOs quando possível.
Qual a definição de POJO você está utilizando? Como mencionei na mensagem anterior o link do Fowler não fala nada sobre isso.
fmeyer
chicocx:
scottys0
scottys0:
Voce pode usar a API de persistencia do ejb 3.0 em tomcat sem sequer precisar do hibernate.
como é feito as configurações de conexao com o banco???
como é feito a consulta/insersão/alteração dos dados ??
usando apenas o tomcat?
Anotations ???
fabriciobraga
O ponto é que eu acabei de entender sua confusão, creio. Quando Fowler fala sobre Entity beans ele fala sobre Entity Beans 2.x, não 3.0. São coisas muito diferentes.
Engano seu. Eu sei muito bem o que é uma coisa e o que é a outra, inclusive expliquei o porque na especificação 2.1 eles eram Business Objects, veja o que eu escrevi lá atrás:
É apenas uma questão de ler com atenção…:o)
Eu não. Nós…:o)
Lá no início eu fiz um “mea culpa” e assumi que tinha usado erradamente o termo “serviços”, ainda sugeri que se fosse apenas essa confusão, que dessemos o debate por encerrado… você deu corda, e eu adoro um debate. Juntou a fome com vontade de comer…:o)
Daí comecei colocando a seguinte afirmação:
“POJOS não são Business Objects”
E é em cima dela (pelo menos eu acho) que estamos discutindo.
Sobre esta definicão ser minha, talvez sim. Mas não apenas minha, existem discussões interessantes onde podemos ver debates similares a este nosso. A conlusão que eu cheguei (sim, esta nossa discussão me fez pensar sobre o assunto…:o)) é que talvez (ênfase nesse talvez) caiba o argumento de que um Business Object seria um POJO quando ele tem seu vínculo “estado-logica da aplicação” minimizado.
Algumas ferramentas se gabam de fazer isso, inclusive o Prevayler faz marketing com isso dizendo:
Inclusive parece não ser apenas definição pessoal sua de que:
E aqui, num forum do Spring, mais partidários seus:
But don’t worry, inheritance has never break POJO-ness. It is a choice you can make, or not. You can perfectly duplicate code and choose another base class or none, in contrary to ejb where there is no choice about it.
Naqueles links que enviei inicialmente há uma artigo muito relevante a esta nossa discussão, onde o autor fala o seguinte:
Alguma discussões interessantes que achei pesquisando rapidamente, alguns defendem seu lado (pra você ver como eu tenho espirito esportivo :o)), outros o meu:
Talvez no final das contas isto tudo seja apenas uma mastrurbação intelectual, sem muito efeito. Porque no dia-a-dia a parte que importa e faz a diferença é como nós modelamos nossos sistemas e fazemos uso da OO. Na prática.
Sim !!! eu sei que anotations mapeia os campos do bean com os campos da tabela, configura id, incremento, relacionamento, etc…
a pergunta é:
*configuração da conexão!!!
*commit dos das alterções no banco!!!
Como???
pcalcado
Oi,
Ok então me explique porque um POJO não pode ser um objeto de negócios e o que seria um objeto de negócios em seu lugar, visto que EJB 3, Spring e tudo mais trabalham com POJOs.
Você não respondeu diretamente a minhas perguntas mas lá vai mais uma: o que seria um Business Object na sua visão?
fabriciobraga:
Lá no início eu fiz um “mea culpa” e assumi que tinha usado erradamente o termo “serviços”, ainda sugeri que se fosse apenas essa confusão, que dessemos o debate por encerrado… você deu corda, e eu adoro um debate. Juntou a fome com vontade de comer…:o)
…
Daí comecei colocando a seguinte afirmação:
“POJOS não são Business Objects”
E é em cima dela (pelo menos eu acho) que estamos discutindo.
Eu não dei corda, eu simplesmente não entendi até agora porque um POJO não poderia ser um Business Object para você.
E você se importa de justificar ou continua sendo um postulado?
Mas heim? No final parece que quem colocou palavras na minha boca foi você então. O que eu disse foi:
É só uma questão de ler com atenção.
Você se importa de dizer porque escalabilidade e componentes distribuídos seriam tão relevantes num debate sobre um POJO ser um objeto de negócios ou não? Eu concordo em grande parte com o que ele falou mas não sei onde você queria chegar com este quote.
Ainda não entendi quais são os lados. Meu lado seria “POJOs não são depósitos burros de dados e podem(devem) ser objetos de negócio”?
Um cara pergunta se POJOs são POJOs se herdarem de uma classe base. Não notei a relevância, pode quotar a parte que acha que cabe neste contexto?
Artigo sobre persistência de POJOs com Spring 2.0 e JSR220. Também não notei a relevância, por favor faça uma citação.
Este fala "Business objects are fine grained POJOs which each represent a single domain model object such as Order, Customer, Address, etc. ".
Mais um que fala sobre utsar POJOs para implementar regra de negócio.
Este fala de POJOs substituindo EJBs para regras de negócio.
Não há nada de errado se você acredita que um POJO deveria na verdade ter essa ou aquela característica. Pode ser que na verdade a sua opinião faça muito mais sentido que todo o consenso atual e que ela seja realmente relevante. Não ia ser nem a milésima nem aúltima vez que isso acotneceria, graças a Zahl.
O que eu te pergunto é o que te fez pensar desta forma, seja este conceito de “POJOs não podem ser Business Objects” uma conclusão que você chegou ou algo que você leu.
Porque pode ser que seja interessante a sua concepção ou o material que anda lendo e eu bem como muita gente não conhecemos e temos interesse real em conhecer.
fabriciobraga
Ehehehe… eu não conhecia esse seu lado insistente. Já percebi que você quer é ter a última palavra…:o)
Então vou lhe dar direito a esta ultima palavra, meu companheiro de forum. É apenas uma pena que você não tenha entendido que os artigos ou links com discussões que enviei são links que fazem menção ao conceito que é o foco de nossa discussão, não necessariamente falam apenas dele.
Encontrar links que discutem diretamente isso, não é facil. Aparentemente este é um debate muito específico, que não tem muita relevância se estamos falando apenas de pontos de vista e de nomenclaturas. Não é facil encontrar quem discuta apenas sobre isso. Pelo menos pra mim, que sou meio tapado eheheh…:o)
O que deve ter escapado aos seus olhos atentos foram as passagens que, como eu falei, faziam menção aos conceitos discutidos aqui.
Como pude ver você foi mais objetivo agora, fez perguntas específicas…gosto disso. Na verdade prefiro assim.
Vou fazer o seguinte, vou responder suas perguntas utilizando na maior parte do tempo texto que já escrevi anteriormente, ok? Vou lhe mostar com isso, que algumas coisas escaparam aos seus olhos, mesmo sendo olhos de um experiente Profissional Java. Sem ironia, nem trocadilhos. Acredite.
Você apenas não leu com a atenção suficiente.
Após este email, vou lhe dar o prazer de ter a ultima palavra na discussão (porque sei que independente do que eu escrever você vai fazer sua réplica), afinal já vi que se não for assim, isso não termina nunca (agora com um pouquinho de ironia). Você não poderá dizer que não sou sincero hein?!
É tudo uma questão de ler corretamente…:o)
Então vamos lá, vou responder suas perguntas bastante objetivas apenas com textos que já escrevi…:o)
Phillip disse:
Ok então me explique porque um POJO não pode ser um objeto de negócios e o que seria um objeto de negócios em seu lugar, visto que EJB 3, Spring e tudo mais trabalham com POJOs.
Você não respondeu diretamente a minhas perguntas mas lá vai mais uma: o que seria um Business Object na sua visão?
Essa é facil, já falei com todas as letras. Mas ponho aqui de novo, já que é o que você quer. CTRL+C… CTRL+V:
Phillip disse:
Não entendi, não foi suficiente a justificativa? Você não acha que tem um pouco de hermenêutica nisso? Estou sendo assim tão absurdamente incoerente? Você comentou isso em cima de um trecho em que eu fui até flexível…:o)
Philip disse:
ehehehe… você não percebeu? Eu apenas transcrevi um texto seu. Só que não fui tão superficial como você pensou meu caro. Eu quis mostrar para você, usando suas próprias palavras, que no final pesam fatores como experiência pessoal e ponto de vista. Parece razoável? Leia de novo o que você mesmo escreveu:
Percebe agora? Você mesmo coloca um ponto de vista seu (que como eu já mostrei, não é apenas seu). Então qual o problema com “pontos de vista”? Porque no resto do email você fica tão absolutista?
Phillip disse:
Esse quote contextualiza os POJOS conforme o que o que eu venho dizendo desde o inicio. Não os define, não bate o martelo, não dá uma explicação definitiva, mas os contextualiza como representações de dados. O artigo inteiro lido, funciona melhor.
Phillip disse:
O meu postulado, dito no início da discussão, lá atrás: POJOS não são Business Objects
Mais claro que isso? Difícil. Ainda tem dúvida de quais são os lados? Eu apenas quis ser honesto meu caro companheiro de forum, e ao ver diversos links corroborando sua idéia achei por bem menciona-los. Calma.
Phillip disse:
A parte que tem relevância é a que corrobora sua idéia, por isso coloquei esse link, como falei acima. Apenas mostrei que ele tem a mesma ideia que você com relação à herança de frameworks. Seja mais flexível Phillip, nem tudo o que vem de mim é pedra…:o)
Phillip disse:
Novamente, este é um artigo onde POJOS são contextualizados, e dele podemos extrair algumas informações relevantes. Algumas quotes do artigo:
Phillip disse:
Este é mais interessante… aqui eu posso mostrar para você apenas usando trechos do artigo o que penso, e inclusive já falei aqui. Vejamos:
Ok… agora veja o que eu escrevi lá atrás (com atenção):
Não está razoável como explanação de um ponto de vista? Apenas você pode ter pontos de vista e observações pessoais? Qual é o problema? No final das contas não é uma questão onde pesam hermenêutica e experiências pessoais?
Phillip disse:
Sim, é verdade. Mais uma vez a velha historia do contexto, veja como ele simplifica os POJOS:
Pronto. Pode ser mesmo que você esteja mais correto do que eu, ou pode ser eu esteja mais correto. O fato é que respondi suas duvidas, e que para mim a discussão chegou a um ponto onde não vamos mais ocnvencer um ao outro.
Procurei ser claro nas respostas, pegar seus questionamentos e reposnde-los. Veja que uma boa parte dos textos eram coisas que eu já havia escrito antes, fui objetivo desde o início.
Você discorda de mim? Ótimo. É isso que faz o mundo legal como é, mas meus argumentos estão aí, respondendo suas perguntas…:o)
Espero sinceramente que não fique mágoa por causa deste debate. Como expliquei antes, pode ser que esta discussão sobre qual o nome/definição correto para o “fulano” seja uma mastrurbação intelectual sem muito efeito prático.
Não, eu só queria que você respondesse perguntas em vez de mandar mil links que não dizem nada.
Fazem menção, onde? O tema da discussão é: “POJOs não podem ser BOs”. Eu acho que nós dois concordamos no que são POJOs e BOs o problema é porque eles não podem se misturar e a resposta não foi dada.
Pelo visto você realmente não vai citar nenhum trecho relevante nos links, né? Então vou supôr que eram apenas links aleatórios e os ignorar.
Não precisa ser exatamente isso, pode ser algo relacionado à sua afirmação que POJOs não podem ser Business Objects.
Vamos ver
Eu estou perguntando desde o segundo post nesta thread, você que ao invés de responder mandou links não relacionados.
Vamos ver.
Meio cômodo isso, né?
Se não for para deixar a ironia de lado realmente é melhor parar por aqui, eu queria saber seu ponto de vista mas você parece querer manter um segredo.
Uhm… ao que aprece um Business Object seria algo que implementa regra de negócio, então por que eu não poderia implementar regra de negócio num POJO? Um POJO é apenas uma estrutura de dados burra?
Isto é uma regra de negócio dentro de um POJO. Pode dizer o que está errado nisso?
Não, não foi nada suficiente e continua como um postulado para mim.
Por que você não pega a frase inteira em vez de apenas o último trecho? Um mínimo de contexto se faz necessário quando se cita alguém, e como colei acima não era sobre isso que eu falava. De qualquer forma, quando disse que (o conceito de POJO-só-se-relaciona-com-POJO) era uma definição minha queria dizer que não é um consenso. Peço que se me citar novamente um dia tenha um mínimo de bom senso e cite ao menos a frase toda.
Absolutista? Eu perguntei a sua motivação trezentas vezes!
Eu li e ele não diz nada de interessante. O que você vem dizendo desde o início? Eu semrpe vejo você dizendo que disse algo mas nunca diz nada além do seu postulado inicial e de links abstratos e confusos. Considerando que eu posso não ter conseguido entender, se importa de explicar com outras palavras?
Ah?
Minha pergunta citada acima foi:
“Meu lado seria “POJOs não são depósitos burros de dados e podem(devem) ser objetos de negócio”?”
Sua resposta foi:
“O meu postulado, dito no início da discussão, lá atrás: POJOS não são Business Objects”
E você acha que foi claro? Desculpe, mas não foi não. Pode ser incapacidade mental minha de entender mas não foi.
Realmente, não é pedra e não é nada. Você por um acaso leu o link? Se não leu eu colo aqui:
Eu não lembro de estarmos discutindo se um POJO herdando outro é um POJO, estamos falando de que Objetos de negócio não poderiam ser POJOs.
Se você puder ter o trabalho de marcar em negrito a parte relevante eu ficaria grato já que não consegui perceber ainda o que isso tem a ver com o fato de você afirmar que Objetos de negócio não podem ser POJOs.
E…?
Você pode explicar o que seria este “vínculo estado-logica da aplicação” e por que deveria ser minimizado? Eu não conheçoe ste termo então seria boms e você fornecesse alguma referência ou o definisse.
Como falei nem TODO POJO é BO e nem todo BO é POJO mas NADA impede que sejam, pelo contrário. POJOs como objetos de negócio é o que faz Spring ter sucesso e EJB3 ser uma boa promessa. Você pode não concordar assim como eu posso te perguntar por que você não concorda.
SIm, por isso eu pedi um milhão de vezes que você explicasse por que pensa isso mas você prefere ser rebuscado e obtuso emv ez de dar uma resposta simples apra que essa discussão chegasse a algum lugar.
E…? O que você quis dizer com isso? POJOs podem ter serviços e é exatamente o que o Spring, por exemplo, faz.
Qual o ponto?
Interessante. Você não respondeu a pergunta inicial ou eu sou realmente muito burro:
Por que objetos de negócio não podem ser POJOs?
Por favor uma resposta direta, sem tritna links obtusos que não dizem nada, sem palavras arcaicas encontradas no dicionário.
Uma resposta simples: “Não pode por isso, isso e aquilo” ou a mais simples: “Porque eu quero e pronto”. Qualquer uma!
Você se achou claro, eu, a pessoa a quem você falava, não. Seu direito se calar.
Bom, eu até agora não sei se discordo de você ou não porque você não respondeu a pergunta inicial.
Fique a vontade, não existem mágoas apesar da ironia desnecessária. O ponto é que eu não vi sua resposta e vou responder a pergunta que pelo visto vai permanecer eternamente sem resposta:
Por que objetos de negócio não podem ser POJOs?
J
julianostr
Isso aqui tá parecendo debate político dos candidatos à presidência de república.
Deve sair algo de bom desse monte de informação aí…
jmp
Sem querer incomodar a discussao aí,
Por quê alguem deixaria de usar EJB3 para usar hibernate?
(Eu estou usando hibernate por que ainda estou traumatizado com entity do ejb2)
fmeyer
jmp:
Sem querer incomodar a discussao aí,
Por quê alguem deixaria de usar EJB3 para usar hibernate?
(Eu estou usando hibernate por que ainda estou traumatizado com entity do ejb2)
sua pergunta nao seria
Por quê alguem deixaria de usar Hibernate para usar EJB3?
chicocx
jmp:
Sem querer incomodar a discussao aí,
Por quê alguem deixaria de usar EJB3 para usar hibernate?
(Eu estou usando hibernate por que ainda estou traumatizado com entity do ejb2)
então voce não conhece o EJB 3 !!! está claro isto !!!
inclusive o Hibernate trabalha junto com o EJB 3, se você não sabe !!!
chicocx
scottys0:
voce ainda nao respondeu minha pergunta !!!:
como usar o EJB3.0 no tomcat sem usar hibernate ?
plentz
chicocx:
scottys0:
voce ainda nao respondeu minha pergunta !!!:
como usar o EJB3.0 no tomcat sem usar hibernate ?
