BMP x CMP

Vou iniciar um novo projeto e pretendo usar EJB, por isso, estou pesquisando a respeito pra saber se realmente é a melhor opção pra este projeto.

O bando de dados desse sistema está todo normalizado, com campo nomeados + ou - assim: ID_FUNCIONARIO, NM_FUNCIONARIO, VL_SALARIO, etc… eu não gostaria de ter um EntityBean com atributos nomeados dessa maneira!

A melhor opção, nesse caso, seria eu utilizar BMP?

Só que os BMP são mais pesados e lentos que os CPM, não é? Sendo assim, como ficaria a questão de performance?

Há alguns dias atrás, eu estava pensando em desenvolver esse sistema como uma arquitetura baseada em beans (Data, Business, etc) e disponíbiliza-los na rede via JNDI, mas… creio que EJB faça melhor o serviço.

Bem, que puder me ajudar… obrigado! :smiley:

Olá le-silva,

Sobre a escolha entre CMP e BMP temos as seguintes considerações:

Vantagens CMP:
[list]
Menos código;
Mais fácil de desenvolver;

[/list]

Vantagens BMP
[list]
Mais controle sobre as relações com o banco de dados;
Possibilidade de reutilização de código SQL (se você já os tem);
Podemos utilizar mais amplamente recursos inerentes do bando de dados;
[/list]

Sobre suas dúvidas

>>> O bando de dados desse sistema está todo normalizado, com campo nomeados + ou - assim: ID_FUNCIONARIO, NM_FUNCIONARIO, VL_SALARIO, etc… eu não gostaria de ter um EntityBean com atributos nomeados dessa maneira!
:arrow: Você poderia definir “Alias” para os campos como
SELECT NOME_COMPLEMTO_DO_USUARIO “NOME” FROM TABLE1;

>>> Só que os BMP são mais pesados e lentos que os CPM, não é?
:arrow: Eu diria que nem sempre, cada caso é um caso isolado; e deve ser analisado de modo a alcançar o melhor design possível da aplicação.

>>> Há alguns dias atrás, eu estava pensando em desenvolver esse sistema como uma arquitetura baseada em beans (Data, Business, etc) e disponíbiliza-los na rede via JNDI, mas… creio que EJB faça melhor o serviço.
:arrow: Sobre esse ponto, acho que a implementação usando EJB / J2EE é bem interessante. Aconselho a utilização de patterns bem conhecidos como o Business Delegate patterns descrito em: http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html

Oi Leandro,

Voce tem varias opcoes para realizar a persistencia de sua aplicacao.
Como voce esta usando um banco de dados relacional, voce deve ser preocupar com o mapeamento objeto-relacional.
Este mapeamento objeto-relacional pode ser realizado atraves de varias formas:

  • programaca JDBC, SQLJ
  • uso de uma camada de persistencia como o TopLink, Castor, Hybernate, etc.
  • uso de EJBs (BMP, CMP)
  • uso de DAO (Data Access Objects - Design Pattern ) geralmente um Session Bean implemantando o mecanismo de persistencia com JDBC.

Cada um desses mecanismos de persistencia tem seus prós e contras.

Caso voce queira realizar a persistencia atraves de EJBs, voce podera utilizar BMP onde dentro desse EJB voce devera “codar” seus metodos de armazenamento e recuperacao de dados, nesse caso, voce devera codar em JDBC por exemplo.
Caso voce opte por CMP, voce deixara que o container realize o armazenamento e a recuperacao dos dados, nesse voce somente tera que definir os atributos que deverao ser persistidos.

O CMP apesar de ser muito atraente ainda nao possui todas as caracteristicas que eu gostaria que tivesse. Por exemplo: A especificacao J2EE ainda nao permite uso de Outer Joins, consultas dinamicas, e algumas outras coisinhas, que dependendo do banco de dados que voce possuir se faz necessario o uso. Alguns containers implementam uso de forma proprietaria, e acredito que nao vale a pena usa-las. perde-se a portabilidade. Alem disso existe o problema das Consultas N+1.

Apesar do BMP lhe dar mais trabalho, este podera lhe dar maior flexibilidade tambem se comparado ao CMP por exemplo. Em relacao a performance de BMP e CMP isso ainda pode ser relativo. Ja vi varios testes de Benchmark onde BMPs era mais rapidos que CMPs, pois os codigos SQL escritos dentro dos BMPs eram mais elaborados e performaticos. O lado bom do uso de EJBs sao os servicos oferecidos e padronizados pelo container, como toda a parte de infraestrutura: Seguranca, controle de transacoes, escalabilidade, distribuicao, etc…

Tambem sei que muitos clientes nao usam EJBs e preferem usar um framework de persistencia, como o TopLink, Castor,etc. Estes ja sao mais maduros que os EJBs e oferecem mais servicos agregados tambem. No caso do TopLink, este existe desde a epoca de SmallTalk, ou seja, o produto ja faz persistencia de dados a muito tempo.

Um abraço