Thanks Jason, Yeah with what I was saying, was that we have made a decision to do explicit transaction rollback etc. handling within each service layer method as opposed to in being_request and end_request in global.asax, the lead developer prefairs it this way. If we where to attempt a session.flush or session.commit in end_request and indeed there was an error for sure we could rollback and maintain DB integrity however how would be handle errors, would we not be limited to just redirecting to a generic error page. I'm planning on rolling back in the service layer, bubbling up to the calling controller and then bubbling up to the specific view.
Also I'm not sure what you meaning by not having to tell NHib of changes? How does it track it automatically? Is that not what currentsession.save/saveorupdate and currentsession.remove for? To tell NH that something has changed? Maybe I don't need it for changes and delete as I most likely get them via load/get as from then on NH tracks in the session but I do need an explicity call currentsession.save right for completely new objects? Again if I need it for some and not others I'd prefare to tell NH explictly about everything (update/new/remove) because we are all new to NH in here, so a reference of how things will work in this app is what I'm trying to put together. Yeah performance of the extra hit to get the last insert will be a hit alright, thankfully our app isn't too performance heavy, with only a few concurrent users. But I've got my hands on NHProfiler recently so that should help with general performance tuning, cheers Jason. On Nov 1, 4:37 pm, Jason Meckley <[email protected]> wrote: > You shouldn't need to inform NH of changes to the domain model. NH is > tracking that automatically. > > "I am using MVC, but we decide to go explicity as opposed to managing > transactions in centralised" > Not sure I understand why you would introduce complexity and duplicated > code, but that doesn't really have any bearing on the topic. > > Back too the topic. > There are advantages to allowing the client (NH) to managing the database > keys. Most of the advantages become apparent when you begin to performance > tune NH is high traffic scenarios. technically speaking identity works, but > conceptually it does not align to the unit of work concepts -- 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.
