I'm trying to write an app that connects directly to the database and uses hibernate to access the database contents. The app is single thread, swing based, directly connected to the database, that is, the usual rich client.

Now, what is the suggested pattern for this kind of app? Consider the following example: I want to model into the database something that looks alike a file system, so I have the File and Folder classes.
Every file has 1 parent folder.
Every folder has 0/1 parent folder, the subfolders and files.

The folder has to be managed as a proxy of itself, and the two collections of subfolders and files are lazy, otherwise I end up loading the whole filesystem in memory at the first data access.

The user interface is a classic explorer like interface, so I have a tree view for the folders and a listview that lists the contents of the current folder. Nodes in the treeview are created lazily, when the user expands a folder.
There are commands to rename, move and delete files (and also to import new files into the database)

What kind of session management do you suggest? If I close the session after each request, I end up with a DAO request and session open/close each time the users moves around, plus the code will be quite ugly.

If I use a single session, would not the session cache grow continuously? The alternative is to evict objects from the cache, but with what rules? Instead of a DAO that closes the connection, a DAO that evicts the cache after every operation? And if I choose this road, wouldn't this cause problems with updating collections (in particular, the ones mapped with the cascade - delete orphan rule)?

Sorry for the long post, but I don't know how to approach this and it seems that most of the people around are developing web apps.

Most of the techniques discussed and documented are valid for both swing and web presentation layers. Don't use a single session object. Think in terms of Unit-of-work use cases (maps mostly to transactions). If it results in a DAO structure then fine. Alternatively, you could build a rich domain layer. I understand your requirements for your application is relatively simple.

The above is just a small piece of a bigger application. But unfortuantely it is the main part of the user interface, meaning that the above tree will stay open for hours with the user interacting with it...
If I model the user interaction with the tree as a single transaction, then the session cache will grow with no limitation, and it is just like having a single session, if I model the single expansion of the tree nodes as a single transaction and close the session, I will completely lose the database layer transparence and will get a counter intuitive situation in which to get a collection property from an object in memory I will have to pass it to the dao before (meaning that I will have to lock the collection in the new session and then expand it). It seems that no matter what, getting true object orientation when dealing with a database is difficult.

I mean, if I don't use the single session for application (which you suggest not to use), I end up with the session per operation (another antipattern according to the documentation), which really means having data objects and functions to retrieve them from the database, which is just a slightly objectified version of the classic query and resultset approach... Don't get me wrong, but from my experience once you close a session all sorts of strange things start to happen (that is, legitemate things from the hibernate point of view, but counter intuitive from the user point of view).

Oh, by the way, what is a rich domain layer?

Another observation. The above folder and file structure is a user oriented abstraction of a system that manages huge amounts of geographic data. So, each file is in fact a geographic layer that is composed of database tables and possibly real files managed on the filesystem (sticking satellite images on the database is not a good solution usually).
Now, one of the File methods is getSize(), which should be polymorphic dependending on the file nature (that is, File is the root of a inheritance hierarchy), some parts will have to contact a server side process that inspects the file size, some others will use database metadata and row count to get an estimate of the space used.

So, I end up with a domain object that has to know something about the persistent layer, or I just spoil it completely and put everything into a DAO object...
Going the first road makes me think of modifying the collection access methods so that they know about hibernate and load the collection when the user gets access to it by opening a session, thus removing the need to go thru the DAO just to get access to the collection contents... this makes the whole thing Hibernate dependent, which is bad. But the other route seems to have a DAO that does it all and a POJO that is just a file name and id...

The very problem with lazy loading and proxies is that the interfaces of your domain object suddendly become a mistery, that is, in the UI layer you don't know what property you can get without getting an exception or without having to call a DAO method just to initialize them. The other road is to have a completely anemic domain model, thus falling back on structured programming (functions and structs).

I can understand your concerns, its nice to see some thought being used. What you are trying to do has many compromises. Thus the result may not be as clean as you would like because of resource issues verses performance verses clean abstractions. Swing's data models boils down to reading POJOs with the appropriate getters/setters wired into the controller. The GUI events result in a action and as such open a node. You are right in your anaysis that you will need to go back to the database to collect the node data as it is expanded in the GUI. The lock does not lock the db (but in your case it would not matter) it just re-introduces the domain object to the (new) session. Rather than have operations for size of images etc in a DAO the method can be located as a part of the domain node thus its a rich(er) domain model replacing or minimising the use of DAOs. The easiest approach is if you don't have to have the tree expand on request (lasy load) if your analysis shows memory usage and initial load time is acceptable then load the lot followed by closing the session. The user selects a leaf node then you collect the image information (or what ever data is appropriate for the leaves of the tree). As much as the Tree control is nice when large amounts of data is involved then a wizard approach might be better, eg, mulitple forms or method to show only a portion of the data at a time (such as a combo box for the first level nodes). This makes it easier to control/minimise the volume of data that is presented. This is sofware engineering - getting the right combination of compromises to solve the problem in the best way.