BMP x CMP

Java Ninja Membro desde: 31/01/2003 10:21:32 Mensagens: 260 Offline

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!

Smalltalk Membro desde: 31/01/2003 10:49:22 Mensagens: 3 Offline

Olá le-silva,

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

Vantagens CMP:

Menos código;
Mais fácil de desenvolver;

Vantagens BMP

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;

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!

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 é?

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.

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

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