For lige at strø lidt salt i såret så skulle måske lige have lidt af de
kritiske punkter omkring brug af ejb'ere.
Her er et lille udsnit taget fra
http://www.javageeks.com/SBJP/index.html.
Jeg kan varmt anbefale at læse linket igennem og have det i baghovedet når
du skal vælge teknologi til dit næste projekt. Du skal i hvert fald ikke
bruge ejb'ere bare fordi det er nyt og spændende.
I couldn't say this in printed form at the time, but the fact is, EJB sucks
as a technology. (See my reasoning why at
http://www.javageeks.com/Presentations/EJBReviewed/01_A_Critical_Look_at_EJB.ppt)
The fact is, it's supposed to make the Java programmer's life simpler
regarding a number of key issues, like remoting, persistence, transactions,
object lifecycle, and so on. Instead, it only serves to complicate the
entire process immensely, forcing Java programmers to learn an entirely
orthogonal set of rules that have nothing to do with the business domain
they're trying to program--exactly the very problem that EJB was trying to
solve in the first place.
Many EJB vendors will then turn around and tell you that their product, in
turn, solves much (if not all--marketing people are shameless) of the
complexity inherent in EJB. I won't argue with this statement; in fact, I
heartily support it--many vendors have some powerful features that can
definitely make your life easier as a developer. Problem is, if you take
advantage of that vendor's functionality, you lose the vendor-neutrality in
EJB that's supposed to let you avoid "vendor lock-in" in the first place. If
you're not interested in vendor-neutrality, why aren't you considering
Microsoft's .NET architecture as part of your vendor evaluations at that
point? Or CORBA, for that matter? In addition, many vendor implementations,
while perhaps easing the burden of developing EJB applications, miss on an
important point--the ability for a Java architect/developer to "hook in" at
certain critical points and provide tuned implementations of various parts
of the system (smart stubs on the client side to avoid redundant
round-trips, smart caching for read-only or read-infrequently data, and so
on).
In short, EJB is a fundamentally flawed specification--a great idea that
just doesn't solve the problems it sets out to solve--and therefore isn't
worth writing about.
MVH
Anders
Bo Gundersen wrote:
> Stefan Kristensen wrote:
>
>> Hej NG.
>> EJB kræver (lidt?) ekstra kode samt en container til serveren. Så
>> vidt jeg kan se, kan en EJB ikke mere end en 'almindelig' bean.
>
> Jeg er ikke sikker på jeg er helt enig i den observation :)
> Når du bruger EJB'er får du (næsten) foræret følgende:
> o Transaktionsstyring
> o Sikkerhed
> o Persistens (v.h.a. container managed persistensy)
> o Clustering
> o + andet som jeg ikke lige kan komme på nu :)
>
>> Så hvad retfærdiggør en EJB?
>
> Typisk lidt større projekter...eller bare lysten til at prøve noget
> nyt :)