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?
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
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.
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???
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.
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.
[quote=“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.[/quote]
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
[quote=“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.[/quote]
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[/quote]
Shoes,
Conhece algum case de aplicação distribuída com reutilização de componentes q não utilize EJB?
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.
]