Boa tarde senhores!
Ficaria muito grato se alguem pudesse trocar uma idéia comigo.
Vejam o meu caso:
Estou desenvolvendo uma aplicação Desktop(Delphi 7) com banco de dados FireBird.
Estava pensando em deixar o delphi somente como camada de apresentação(Cliente), e colocar meu objects business num servidor de aplicação, sendo que a aplicação tem tendencias de ir pra web depois.
Só que teria que ter um web service pro delphi acessar minha lógica de negócios certo??
Como poderia fazer isso?
Uma pesquisada aqui e suas dúvidas acabam, ou pelo menos se iniciam
Mas você está no caminho certo…
[]s
G
guilhermeguerraPJ
Blz…valeu…
Mas pro delphi consumi o web service eh barbada… neh… o problema eh arquiteturalmente falando…
Digamos:
Tenho um aplicação desktop que eh minha camada de apresentação.
Tenho um servidor de aplicação com minha logica de negocios.
minha camada de persistencia seria EJB ou somente minha regra de negocio ficaria no EJB e teria mais uma camada para persistencia?? isso que naum tenho muito claro ainda???
meu webservice implementaria os EJB’s, ex:
EjbCliente —> WsCliente?? a classe WsCliente instanciaria a classe Ejb e acessaria seus metodos?? tipo getNome() e tal???
e o delphi receberia o WS…
Alguem poderia me dar uma Luzzzz… valew…
[]'s a todos
P
pcalcadoPJ
Você pdoe até usar essa arquitetura, mas qual o bom motivo para usar EJB [aviso logo: não existe bom motivos para usar EJB… ]
[]s
G
guilhermeguerraPJ
Certo… hehehe
Acho que vou usar DAO, é uma boa solução neh?
Assim evito a complexidade dos EJB’s.
[]'s valeu, pCalcado.
G
guilhermeguerraPJ
*-----------
M
matheusPJ
eu faria os EJBs de negocio acessarem o DAO… e não o cliente acessar o DAO direto…
P
pcalcadoPJ
Matheus,
Por que EJBs? Aidna não achei um bom motivo para isso…
Na verdade, os clientes não acessao o DAO direto porque nem sabem que ele existe. Existe a camada de negócios, com as classes de domínio, que são, estas sim, clientes do DAO.
[]s
M
matheusPJ
nem li o topico todo, heaheahea, mas eu opto por EJB qnd a aplicação tem de ser distribuida, com várias máquinas clientes…
G
guilhermeguerraPJ
matheus e pcalcado, estou fazendo da seguinte forma:
Sem ejb’s,
mas a camada cliente não acessa diretamente a DAO, tenho uma “camada” de negócio antes, e estas sim são clientes da DAO, como o pcalcado falou.
Se fosse usar EJB não teria uma perda de performance com essa camada a mais???
[]'s e mais uma vez obrigado.
P
pcalcadoPJ
Não tem porque usar EJBs. Na boa.
EJBs são sobrecarga demais para 99.999% dos sistemas, a funcionaldiade de transações distribuídas e mapeamento o-r podem facilmente ser obtidas por sistemas mais leves, como Hibernate e Spring.
Fujam do hype EJBs, só legado…
Mas, é claro, são opiniões…
[]s
M
matheusPJ
ai esta falando de beans entity… eu digo session acessando dao pro negocio… qnd for distribuido.
P
pcalcadoPJ
Não senhor, estou falando de EJBs de maneira geral. Programar com Session beans é um convite à programação estruturada e ao acoplamento.
Não dá pra conceber algo que me force a implementar 1 milhão de itnerfaces para fazer um HelloWorld.
[]s
M
matheusPJ
Não senhor, estou falando de EJBs de maneira geral. Programar com Session beans é um convite à programação estruturada e ao acoplamento.
Não dá pra conceber algo que me force a implementar 1 milhão de itnerfaces para fazer um HelloWorld.
[]s
bem, oq eu posso dizer, só discordo. :uy:
A
amhfilhoPJ
Para implementar Web Services no EJB, obrigatoriamente seu EJB deve ser um Stateless Session Bean , que implementa os métodos que serão descritos no WSDL. Para persistência, você pode usar tanto DAO como Entity Beans. Não vejo problema em usar EJB, a não ser que você precise de um desenvolvimento mais rápido (o aprendizado de EJB é mais lento). Se você quiser tornar seu sistema realmente distribuído, com total reutilização de código e implementação simplificada, utilize EJBs, pois todo este trabalho é feito pelo App. Server. Se você for usar DAO, toda a aplicação que for utilizar de sua lógica de negócio vai ter que importar seus jars.
No livro Mastering EJB 3rd ed. tem algumas justificativas para utilização dos mesmos. Mas é questão de opinião.
P
pcalcadoPJ
Por que, Matheus?
“amhfilho”:
utilize EJBs, pois todo este trabalho é feito pelo App. Server. Se você for usar DAO, toda a aplicação que for utilizar de sua lógica de negócio vai ter que importar seus jars.
No livro Mastering EJB 3rd ed. tem algumas justificativas para utilização dos mesmos. Mas é questão de opinião.
Não tem muito sentido isso.
Não é apenas EJBs que te dão (e não necessariamente eles dão) n-camadas. Cuidado com a literatura sobre EJB, procure cases
Shoes
T
TazPJ
“pcalcado”:
Por que, Matheus?
“amhfilho”:
utilize EJBs, pois todo este trabalho é feito pelo App. Server. Se você for usar DAO, toda a aplicação que for utilizar de sua lógica de negócio vai ter que importar seus jars.
No livro Mastering EJB 3rd ed. tem algumas justificativas para utilização dos mesmos. Mas é questão de opinião.
Não tem muito sentido isso.
Não é apenas EJBs que te dão (e não necessariamente eles dão) n-camadas. Cuidado com a literatura sobre EJB, procure cases
Shoes
Shoes,
Conhece algum case de aplicação distribuída com reutilização de componentes q não utilize EJB?
P
pcalcadoPJ
Depende do que você chama de aplicação distribuída.
Clientes Swing com regras em um servidor? Sim, com RMI, SOAP, XML/HTTP e DualRPC.
Container Web separados? Sim, containers integrados com mesmas tecnologias acima.
Cluster na camada de negócios? Ainda não
Shoes
T
TazPJ
Sei q eh uma questão de arquitetura… mas…
Pq containers web separados? Essa solução resolve qual problema?..
P
pcalcadoPJ
Olá, taz,
Por exemplo, para fazer distribuiçãod e carga. uma aplicação muito acessada pode ter vários servidores web dvidindo os acessos e utilizando os mesmos recursos.
Outro exemplo é quando voce tem diversos tipos de clientes (Swing, Web, WebServices…) e quer manter o servidor central, onde está a lógica de negócios, independente de interface.
Shoes
A
amhfilhoPJ
Eu trabalhei em um projeto onde havia 2 nós Webspheres (2 máquinas) e a requisição web era feita pelo Network Dispatcher para balanceamento de carga. Funciona bem também
D
dtorresPJ
“pcalcado”:
Não tem porque usar EJBs. Na boa.
EJBs são sobrecarga demais para 99.999% dos sistemas, a funcionaldiade de transações distribuídas e mapeamento o-r podem facilmente ser obtidas por sistemas mais leves, como Hibernate e Spring.
Fujam do hype EJBs, só legado…
Mas, é claro, são opiniões…
[]s
Concordor plenamente, antes estava usando DAO e EJB e estava tendo um puta trampo com isso. DAO nem tanto…mas depois comecei a pesquisar Hibernate e iBatis, acabamos escolhendo o Hibernate que simplesmente tirou um caminhão da nossas costas
]
