Hi,
thats a good point. An other one is, that one might like to add
properties / methods that don't need to be persisted. I personally
would put those things in domain classes like Song and Album.
loproman schrieb:
Hi Jukka,
I appreciate the input. You make a good point about the session lifespan in
contrast with desktop and web application paradigms. On my class example, if
I might defend my thinking a bit it seems like in larger systems, the
loosely typed nature of JCR objects (in particular Node and Property) could
become a problem. Unless these are wrapped with objects, I could imagine
there being many references to the same node in many places.
For example, I need to change the underlying type of a property "myprop"
from Long to Double. If not wrapped, I'd have to hunt down cases of the
following throughout my application.
Property p = node.getProperty("myprop");
Long l = p.getLong();
Unfortunately, this may not be written the same way every time, so it's
likely I miss a few instances and introduce bugs. With a wrapper around a
node, I'd change it in once place and the compiler would enforce the change
throughout the application for me based upon strongly typed references.
Aside from being strongly typed, I feel like it presents opportunities to
build in domain logic on top of my nodes. My example probably did a crummy
job of illustrating additional benefits, but one idea might be to have Album
implement a Comparable interface. Or maybe I might want to pass an album
into a RecordPlayer object. It just seems more OO friendly to me, although I
will concede it's going to be more work.
Jukka Zitting wrote:
Hi,
On Nov 7, 2007 12:38 PM, loproman <[EMAIL PROTECTED]> wrote:
What are your thoughts? Am I doing anything that might cause issues as
things get more complex? I'm new to the concept of JCR, so I'm very
interested in learning how I can use it in my code as naturally as
possible.
I wouldn't use your Album and Song classes as they are now, as their
methods are essentially just wrappers around equivalent JCR methods.
Such a data access layer is more useful for JDBC, where a method like
Album.getName() could become:
public String getName() throws SQLException {
PreparedStatement ps = connection.prepareStatement(
"SELECT name FROM albums WHERE albumid=?");
try {
ps.setString(1, albumid);
ResultSet rs = ps.executeQuery();
try {
if (rs.next()) {
return rs.getString(1);
} else {
... // handle error
}
} finally {
rs.close();
}
} finally {
ps.close();
}
}
No wonder why frameworks like Hibernate are popular...
Also, how long should sessions live? With relational databases, best
practice
is to open and close the connection as quickly as possible. However, it
seems
like JCR sessions can/should stay open much longer.
It depends on your application. A standalone client is probably best
served with a single JCR session (just like a single JDBC connection
would be a good idea), but a webapp serving multiple independent and
concurrent requests should probably (unless it wants to leverage the
transient space for handling unsaved changes) use a session pool or
start separate sessions for each request.
BR,
Jukka Zitting
