Best way to handle persistance? Web frameworks?

[Kenneth P. Turvey]

I picked up a book on hibernate the other day. I've decided to stop
writing my own persistence layer every time I need one. So I also looked
on the web and found out that Java now has the Java Persistence API.
Hmm.. A friend of mine says that the way to handle these tasks today is
with AOP, something else I'm unfamiliar with.

So, what is the general consensus? What is the best way to handle
persistence in Java today?

And while we're on the subject.. what is the best framework for doing web
programming today? Why?

Thanks.

 

[Wayne]

I picked up a book on hibernate the other day. I've decided to stop
writing my own persistence layer every time I need one. So I also looked
on the web and found out that Java now has the Java Persistence API.
Hmm.. A friend of mine says that the way to handle these tasks today is
with AOP, something else I'm unfamiliar with.

So, what is the general consensus? What is the best way to handle
persistence in Java today?

...

Java SE also has a preferences API, great when all you need is
to persist a small amount of data (e.g., window positions, user
selected options, etc.)

Java SE also supports (the Apache Derby) database, either as an
embedded DB or (with more configuration effort) a stand-alone DB.

Using either may be an alternative option to EE solutions and frameworks.

-Wayne

 

[Kenneth P. Turvey]

Java SE also has a preferences API, great when all you need is
to persist a small amount of data (e.g., window positions, user
selected options, etc.)

Yeah, I use preferences all the time. They're terrific for this sort of
data.

Java SE also supports (the Apache Derby) database, either as an
embedded DB or (with more configuration effort) a stand-alone DB.

Using either may be an alternative option to EE solutions and frameworks.

I've just started using derby. Before that I often used hsqldb. They are
both great tools. The problem is that from the client end these still
look like full fledged SQL databases. With hibernate you can hide some of
that, and make your code more portable.

Ideally, I'd like a solution that hides most of the database stuff and
allows nearly complete portability. The end user should be able to select
which database back end they want to use with my product and everything
should still work. This just isn't possible with hand crafted SQL.

It really sucks that we have a standard language for handling database
queries and construction, but that it doesn't do us any good in writing
portable code. If every C compiler was different to the degree that SQL
implementations are, we would still be using FORTRAN.