I am bringing NHibernate into an existing project where there is a pre- existing roll-your-own persistence. These two persistence mechanisms have to co-exist. The application is a single user, desktop application. It is not a typical line of business application but more of a designer tool for specialized hardware.
To date and in the preceding generation of application, the user goes about their work and then does a "Save". We can't get away from the Save model as this is what the users have come to expect. 1) Should I be building the persistence components to avoid actually calling Save methods until the Application calls Save, then explicitely call Save? If I go this route then I lose some of the goodness about the generation of IDs, move to assigned IDs, and then have to track if it is a new\update. I had a thought that maybe I could be using a session (keeping it open) and only flushing the session on save. 2) My colleague feels that on update (FileSave), both persistence mechanisms should share the same transaction. My thought is that from an application perspective the object models represented by differing persistence models don't relate except at a very high level, so they don't need to be in the same transaction. I am also having some difficulty in thinking that a transaction needs to wrap up all of the activity between saves. A single error might roll-back a whole lot of un-related activity. And, in the grand scheme of things we aren't doing banking here... I am still new to the NHibernate model so I appreciate any comments that anyone may have. Thanks, jeff --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
