Hi all.

When I adopt the session-per-request + lazy-load paradigms in a web application, for each request my object graph is automatically loaded just up to the needed data. And this preserves efficiency. Is it right?

How to behave in a stand-alone application?
I have persistent instances which are stored also into the GUI layer, and I don't know at what extent their graph will be used by the application. So, can I keep on using the session-per-request (or better session-per-action or session-per-usecase) paradigm?

If no, I suppose I have to give up also for what concerns lazy-load.

If yes, is the object graph completely loaded for each loaded instance?

Thanks for your help,
Marcello.

Well, we're using the session-per-usecase (aka per one "view" (base form)) plus session-disconnection (so there are no long connections to a database).

It look something like this:
1) user opens a form (np "manage books")
2) a session is created
3) a list of books is loaded (paging and stuff)
4) the session is disconnected;
5) user sees the list of books;
6) user types a filter in;
7) the session is connecting (but it's still the same session, loaded object are the same, lazy loading is working);
8) a new list of books is loaded (not using lazy loading here yet)
9) the session is disconnected;
10) user sees a new list;
11) user clicks on a book (wants to edit it);
12) an edit form is shown
13) the session is connecting (still the same session)
14) the book is shown, user edits it, lazy loading can be used here;
15) user clicks "ok";
16) the session is disconnected;
17) user closes the view (manage books)
18) the session is closed permanently

As you can see, the GUI events are driving "application session" (by invoking methods from the service layer).
And you have to remember that when data are changing fast you need to reload objects frequently and there have to be use some sort of versioning!

Of course some views need to be handled a bit differently.

Thank you for your prompt response.

>> 4) the session is disconnected;
>> 5) user sees the list of books;

Probably I'm missing some point here.
If the user, while exploring the list, asks for a lazy-loaded book property (e.g. author details), how do I reconnect() the session?

Maybe I'm wrong, in that I store lazy-loaded book instances in the Tag property of the books-list-view (because this seems to me somewhat OPF agnostic). So, when the user asks for a property, I simply have to get and show such a property, e.g.:

Book b = (Book)(ListView.SelectedItems[0].Tag);
WriteLine(b.Author.Name);

...and I get something like "Cannot load proxy - Session is disconnected".
Maybe, I would need some sort of "autoreconnect-on-lazy-load" behaviour.

Or are you thinking to store just the book ID within the list visual control?

Thank you,
Marcello.

> If the user, while exploring the list, asks for a lazy-loaded book property
> (e.g. author details), how do I reconnect() the session?

Well, you need to intercept the "asking for a lazy-loaded book property" and connect the session. After the "asking" you need to disconnect.

So you need some kind of "application session controller". In our project we have a "domain session" which is a fasade for the ISession accessible in domain layer. And services (a use-case controllers) can access them.

So your example would look like this:


void btnShow_Clicked(...)
{
_controller.EnableSession();

Book b = (Book)(ListView.SelectedItems[0].Tag);

tbSelectedName.Text = b.Author.Name;

_controller.DisableSession();
}

or

void btnShow_Clicked(...)
{
_controller.EnableSession();

ShowBook((Book)(ListView.SelectedItems[0].Tag));

_controller.DisableSession();
}

Unfortunately as far as I know there's no "autoreconnect-on-lazy-load".

Let's move to the "object id in visual stuff". Sometimes it's better sometimes not, it depends on a use-case. For instance if you have a "fast changing" table in db and one user only picks an object to work with, the session disconnection is not good. It's better to open/close session each time so there's no stale data. Open/close is slower then disconnection but if user doesn't do much with a filter (search) it doesn't matter.

And remember, sometimes lazy-loading is your enemy! If you would like to show the author's name is the grid while author is lazy loaded, it will hit database as many times as count of rows in grid! Then it would be better for you to turn off the lazy-loading on author.

BTW: don't confuse the controller which i'm talking about with MCV ;)