jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Böhme <sandro.boe...@gmx.de>
Subject Re: Jackrabbit Best Practices/Design Patterns (an attempt)
Date Fri, 09 Nov 2007 21:06:09 GMT

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 <loproman@gmail.com> 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

View raw message