I don't think you can simply blame EJBs for your development aches. EJBs
provide you with several features, such as security, transaction,
persistence, distributed. Naturally the container needs to generate classes
to do this work for you. Otherwise you'll endup writing this code for
yourself. So, do you want to have a lot of classes generated by the
container or a lot of classes your developers code? If you don't need these
features then don't use EJBs. Regarding deployment time. Yes, EJBs require
an extra step but this should in general not cause you all the pains you
speak of. You can write scripts that pretty much does all the
compiling/deployment for you. And depending on how you design your
application you often time don't have to redeploy your beans at all unless
some major interface changes. It could also be that you are not unit testing
your code enough. If you are waiting to discover bugs only when you deploy
your stuff I think it's a little too late to complain.

_________________________________________

Tinou Bao
BAO Systems
Chairman of the Board and Chief Software Architect
www.baosys.com

----- Original Message -----
From: "Hu Shih" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 30, 2002 10:08 AM
Subject: [EJB-INT] EJB Development Cycle


> Please forgive my frustrated tone, but
>
> I've been working with EJB (CMP beans with session facades) using Sun's
> J2SDKEE.  I find the development cycle extremely tiring and slow.  I write
> bean code.  I go to their deploytool to deploy it.  I run the thing.  Find
> problems and come back to my development environment.
>
> I understand some IDEs will make this cycle easier.  Still, I've been used
> to developing and testing code quickly in an iterative cycle.  After many
of
> these iterations, I deploy to user environment--many
code/compile/test-runs,
> very few deployments.
>
> One of the big advantages of a quasi-intrepretive language like Java is
> precisely that the repetitive code/compile/test-run cycle is quick.
>
> EJB changed all this.  They stuck a rather long, tedious, and often
painful
> deployment phase right between compile and test-run, often breaking the
> development cycle with 10 to 20 minute breaks.
>
> Debugging such a deployed app is a nightmare.  Because EJB (especially
CMP)
> generate so many classes and because so many of these are system generated
> stuff, I have very little idea what's going on or what I have done wrong.
>
> Also, so much information that are important to developers are hidden away
> from them in multi-level jars/ears/wars, etc. (and these things are
> humongous).  And, why so many classes?  When running, I see over 4 classes
> generated for each EJB bean.  This is excess and debugging nightmare!
>
> With Java, the trickiest configuration parameter was CLASSPATH.  With EJB,
I
> have to know and worry about so many of these configurations, I feel like
I
> need a dictionary of them.
>
> What's going on?  It's almost as though EJB put Java back to the level of
> C++ and C++ templates.  I don't know about others, but I generalize
dislike
> and dispise the condescending attitude of any system that tells
developers:
> "Don't worry.  We'll take care of you by generating lots of stuff under
the
> covers.  Why would you care about long breaks in the development cycle?
Go
> take a coffee break."
>
> Developers are an impatient and controlling bunch.  Java has been good
> because it gives speed of development and gives enough control for
> developers.  In my opinion, EJB is going backwards (the wrong direction).
> Is there an effort to address these?  Or, is it that to be an EJB
developer,
> you have to take all this willingly and gladly?
>
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST".  For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to