Ok, it sounds reasonable. But where validation that requires database query should be placed?. Should it go before business operation, that changes entity state? Pre-validation also would cause bugs, especially in case of complex business rules.
On Aug 14, 3:58 pm, Stefan Steinegger <stefan.steineg...@bluewin.ch> wrote: > I wouldn't evict anything. Just my opinion. > > There is no persistence ignorance if you can tell the persistence > layer to undo some changes in memory. If you implement as if there is > no persistency, you don't expect to be able to undo a few changes you > made in memory. There aren't "two layers" of changing data. So if you > change anything in memory, the changes is already done. There are > always two options: Commit or Rollback the whole stuff. > > So my suggestion is: implement as if there wasn't a database. Rely on > transactions, they are important, to make it atomic (all or nothing). > Don't think in doing stuff in memory first and then choosing what, > when and how to write it into the database. > > On 14 Aug., 14:03, vitalya <vitaliy.litovs...@gmail.com> wrote: > > > Hi everyone, > > Recently i've also faced similar problem. First i've posted a <a > > href="http://groups.google.com/group/castle-project-users/ > > browse_thread/thread/f2fc359da7228fca?hl=en"> question</a> to > > castleproject-users group, but than after deeper investigation it > > turned out to be the NHibernate behavior. > > I'm working in the web context, so my scenario is the following: > > 1. Get entity from repository by Id > > 2. Bind simple properties (like string, integers etc.) > > 3. Bind Many-to-one properties (like User.Country) > > 4. If binded entity is valid - persist changes, otherwise show > > validation erros and DO NOT SAVE invalid dirty entity. > > > With default auto-flushing dirty objects behavior i get the following > > problems: > > 1. During the step3 i have to query database to get entities > > references as many-to-one. Sometimes Session.Load is not suitable and > > i have to query database, that causes unwanted flushing. > > 2. During validation i also might need to query database (to check > > Unique constraints), than also causes unwanted flushing. > > > Currently i see few possible ways, but they are not brilliant: > > 1. Use FlushMode.Commit. The disadvantage here is that during > > executing select statements the result won't be relevant, because > > valid not flushed changes to the entities won't be taken into account. > > 2. Forget about persistence ignorance and use evict and attach to > > session approach within business logic code > > 3. First bind to in-memory DTO, check if data is valid and only then > > map changes to the real entity. But this approach will produce a lot > > of extra code and bugs. > > > If there are no other ways i'm going to choose manual Evicting. > > Am i missing something? > > Thanks for your help --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to nhusers@googlegroups.com To unsubscribe from this group, send email to nhusers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
