I think the key thing I said that everyone's forgotten is if you have data
that's being read a lot more than being written (like 10,000 reads / sec
compared to 1 write / month) then beans might be a good choice. In this
case, the overhead of creating and destroying the bean is trivial (1 time
/ month). Also keeping the been up to date is a trivial matter.
Things like the menu system on photo.net, for instance: data that doesn't
care that it may be a little behind the database... data that is
hardly ever changed, but you still don't want to hard code.
I agree changing data is best left to the database 100% because the
database is good at that kind of thing..
On Wed, 2 May 2001, Alan Wright wrote:
> Tim
>
> Destroying and instantiating beans is a very expensive process and if your site gets
> busy be sure you will regret such an approach.
>
> Our Tomcat ( http://www.free-minder.com ) site uses vanilla javabeans where user
> data is applied to bean properties and then database update methods are provided to
> make changes persistent as appropriate. We have made the source to the site
> available for download if your interested. We are not experts in Java so this may
> not be the "proper way", this was just the way we did it.
>
> >From a career point of view you are sensible to get Java experience because there is
> a lot of well paid java work (here in the UK at least). I am just about to put my
> life savings on the line to build a subscription driven web service so my priorities
> are not future employment driven!
>
> Good luck with your EJB work - it would be interesting to compare notes in 6 months
> after we we have both crossed over, albeit in opposite directions.
>
> Tim Darling wrote:
>
> > If a value needs to be updated, you write to the database and then kill
> > and remake the bean. This way you're keeping the database as your sole
> > data abstraction, and the beans are just a local mirror of some parts.
> >
>
