fordele og ulemper ved sessionbeans vs. entitybeans ?

Det er 2 helt forskellige ting.

Session beans er en service (kode som gør noget).

Entity beans er data objekter (data som der gøre snoget ved).

De kan ikke erstatte hinanden.

Hvis entity beans er CMP så genereres det meste af koden. Ikke hvis den er
BMP.

Entity beans er nok noget af det mest kritiserede i J2EE. Der er mange
som er utilfredse med dem.

De leverer en masse features.

Men ifølge kritikken så:
  - har de færreste brug for de features
  - de kan være ret tunge performance mæssigt

Du har ret arne_v. de kan ikke erstatte hinanden. det spørgsmålet lyder på er faktisk ulemper og fordele ved den ene implementering frem for den anden.. my bad... altså om man skal implementere komponentobjekter i normale java klasser eller som enitybeans?

Det med de mange features skal vel ses i lyset af at der er mange forskellige organisationer med forskellige behov, der har været med til at udvikle ejb miljøet....

http://www.onjava.com/pub/a/onjava/2003/05/21/jdo.html

De afgørende faktorer for om du vil bruge entity beans eller ej må primært
afhænge af:
  - har du brug for nogle af de features entity beans tilbyder (remote
    access, declarative transactions, clustering) ?
  - egner din data tilgang sig til entity beans (bruger du objekter
    som enkelt objekter) ?
  - satser din organisation på J2EE app-servere ?

3 x ja => entity bean med CMP er et godt valg

ellers skal skal du nok overveje alternativer (den artikel som
mfalck linker til sammenligner med et af alternativerne JDO - jeg tror
dog at Hibernate er et mere hyppigt valg idag).

hvis du stadig godt vil have declarative transactions så kunne du kigge på spring sammen med hibernate eller jdo som gør det hele rigtigt nemt.

Jeg vil også foreslå dig at læse "Expert One-on-One J2EE Development without EJB" - Rod Johnson, Juergen Hoeller. hvis du vil have en mere dybdegående beskrivelse af problemerne men også fordelene ved ejb.. samt løsningen "spring" ;) .. god bog som dog er farvet af at det er udviklerne af spring der står for at udele kritikken.

Kan du uddybe de her punkter arne_v og poste et svar

  - har du brug for nogle af de features entity beans tilbyder (remote
    access, declarative transactions, clustering) ?
  - egner din data tilgang sig til entity beans (bruger du objekter
    som enkelt objekter) ?
  - satser din organisation på J2EE app-servere ?

Du kan give din entity bean et remote interface så den kan tilgåes fra en session bean
på en anden maskine. Det koster men er godt for skalerbarheden.

Declarative transactions gør at du via dine deployment descriptorer kan styre
hvornår der oprettes nye transaktioner og hvornår der fortsættes i samme
transaktion.

Clustering gør at app-serveren selv vedligeholder/distrubuerer/synkroniserer
en cached kopi i memory.

Entity beans er gode til:
  hent en record
  ret den
  gem den igen

Entity beans er dårlige til samme operation på millioner af rækker. Dårlige
som i dårlig performance.

Hvis dit firma udvikler alle eller ihvertfald de fleste af sine nye
systemer J2EE baseret, så er der nogle gode muligheder for at genbruge
komponenter ved at vælge samme teknologi.

Omvendt hvis resten er f.eks. Microsoft teknologi, så kan man ikke genbruge
og man har alt besværet med at vedligeholde et fornuftigt drifts miljø.