I'm afraid that I can't be of much help here. I'm working on a client- server project on the server side.
Generally I would say that you have two options: - open the session when the user starts editing (if you know this point in time, eg. if he opens a editor) and close it when the user either stores or discards the changes. - open the session when the user stores the changes. I think, the last is very simple and straight forward. Again, I'm not an expert in this kind of applications. Probably having a session for the whole lifetime of the application would also work somehow. But consider, if NH throws an exception, the session is out of synch and shouldn't be used anymore. Things are just much simpler if you create a new session for all independent user actions. If you want to use long sessions (longer then the time of a button press), you should still make short database transactions. Having an open transaction while waiting for user input is a very bad idea if you have more then one client, because of the locks. On 5 Mrz., 10:31, antoschka <[email protected]> wrote: > Hi, > > your approaches sound very interesting. I face the problem that I > develop my first NH application and therefore I'm not very familiar > with best practices of architectural issues. I gave me some keywords > which make much sense to me. Do you know any source for a detailed > description for MVC- Pattern in conjunction with NH. > For example. I face the problem that my Business Objects do not match > my mapped classes so the model-part of mvc is a kind of tricky. > Refering to your mentioned options I would be also intersted in a > smart way of session handling. At the moment I do have Singleton-based > SessionManager which opens the session when I start my Win-App and > closes it when I close my Application. > > Thanks for feedback > > antoschka > > On 4 Mrz., 21:41, Stefan Steinegger <[email protected]> wrote: > > > As I know, the referenced entities in the bag are only evicted if they > > are mapped with cascade=all. That's the reason why I stopped using it. > > > If I where you, I wouldn't use evict and refresh to discard changes. > > As I understand it, it is not designed to couple it directly to user > > actions. Evict has this cascading problem, making it very dependant of > > the mapping and easy to break. Refresh reloads the state that has been > > stored to the database. This means, if NH already flushed some changes > > (eg. before a query), changes are not undone. You actually can not > > determine which changes made within the session are undone. Only that > > changes made outside of the session are undone for sure. > > > I would do one of these: > > - When you store: open the session and persist all the changes, commit > > and close the session. > > - OR When you start editing open the session and either commit or > > rollback the changes. > > - OR deep-copy the data for the editor and either throw away or merge > > the copy. > > - OR copy the entities to a model (model-view-controler architecture) > > and only copy it back when you store (same as above). > > > On Mar 4, 3:45 pm, antoschka <[email protected]> wrote: > > > > OK, after hours of trial & error I have a solution, but do not > > > understand why it did not work before. > > > > What happens. > > > There is UI with bound data. the user enters something leave the edit > > > field end later decides: > > > -either to save the data or > > > -to discard changes > > > > what I did was: > > > - before the data was changed I set the bound entity session.Evict > > > (boundItem) > > > - in case the user decided to save changes, I tried to merge the bound > > > Item and then invoked a session Flush ( there the error came up saying > > > an object with same identifier is already there, although I checked > > > before session.Contains(bounItem) and it returned as expected "false") > > > - in case of discarding changes I did session.Refresh(boundItem) > > > > in fact what I did was to skip the first two steps and now it works - > > > probably risky is the fact the possibility of an intended flush before > > > a possible refresh (i work with default FlushMode). > > > > What's surprising to me is, that I originally thought that my initial > > > proceeding is the exact use case for evict & merge. > > > > Working with lazy initilizations of one-to-many bags I do have a guess > > > and would like to know if this could be the case. Is it possible that > > > I evicted my boundItem but a proxy of one of my many-to-one bags was > > > not aware of being proxy of an evicted object. > > > After Merging the following check for the existence of the object and > > > found a proxy which corresponds to my bound Item. > > > > Could that be the case > > > > Thanks in advance for your feedback > > > > antoschka > > > > On 4 Mrz., 14:10, Fabio Maulo <[email protected]> wrote: > > > > > 2009/3/4 Stefan Steinegger <[email protected]> > > > > > > var attachedObject = session.Merge(detachedObject); > > > > > Assert.IsTrue(session.Contains(attachedObject)); > > > > > > Don't use attachedObject anymore, it is not in the session an must not > > > > > be referenced by any attached instance. > > > > > > I don't really understand why you use Detach. You should not use > > > > > Detach, > > > > > It depend for what you are using Merge... StaleObjectStateException ? > > > > ;) > > > > -- > > > > Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
