I try to explain it again. Don't rely on the fact that there is a database. Validation should not occur before changes are persisted, but when they are done (in memory, by the business logic).
Making changes in memory but not storing them is NOT the solution. How would to reliably validate entities if you have invalid data in memory? How would you calculate the price of an order when you allow any part of the software changing the price of a product in memory? Your memory needs to be as consistent as the database. Automatic dirty checking means, that all changes will be persisted. It is a problem of your application if you don't know which part of the application changes which entities and therefore you don't know where to put validation logic. By the way, to prevent others to perform changes on entities they shouldn't, you can implement immutable interfaces which only consist of references to others by immutable interfaces. the problem here is, that C# does not have the const keyword as C has. This is missed in many places which is also not related to NH. When working with DTO's (what most people in large projects do), this is not an issue anyway. You'll have a "SafeProduct" method, which takes a DTO as argument. This method applies only the values that are changeable to the entities, and validates it. There is a feature by NH that allows validation within the entity at the point in time before it gets persisted. Just implement the interface IValidatable (see http://knol.google.com/k/fabio-maulo/nhibernate-chapter-4/1nr4enxv3dpeq/7#4%282E%295%282E%29%28C2%29%28A0%29IValidatable_callback). (This is of course only meaningful for validation within the aggregation boundary.) If your application depends on an existing dirty check mechanism, you could write an interceptor which calls it. http://www.surcombe.com/nhibernate-1.2/api/html/M_NHibernate_IInterceptor_FindDirty.htm You could also validate in a OnFlushDirty: check all the entities which are going to be stored, and throw an exception if they shouldn't change. It would be a programming error. Not sure if this is worth the effort. On 24 Aug., 08:52, Oskar Berggren <oskar.bergg...@gmail.com> wrote: > 2009/8/22 kurtharriger <kurtharri...@gmail.com>: > > > > > I also would like to go on the record as saying that I too believe > > dirty checking is a a bad idea and probably should be considered a bug > > because it violates encapsulation boundaries. > > I disagree with your terminology. I consider a bug to be a "violation > of specification or intended behaviour". Auto dirty checking is > intended. What we have here I would call a feature request, since the > ability to completely turn of auto dirty checking would be a new > feature. > > > The leakage of mutable > > references makes it difficult to verify that business rules always > > remain valid when changes are persisted. You can read more on my blog > > here: > > >http://kurtharriger.wordpress.com/2009/08/21/how-nhibernates-dirty-ch... > > I too have at times pondered whether dirty checking is good or bad. > However, some comments on your article: > > You make the example of trying to add to lineitems, first succeeds, > second fails, but then one is persisted anyway. You state the solution > to this yourself: Rollback the transaction. I don't see how this would > logically couple your application to NHibernate, since transactions is > a much more general concept and not something that NHibernate > introduces. I think the rule is quite simple: "If there is an > exception in you UoW, then the associated transaction should/must be > aborted." > > But like I said, I have also struggled with how to enforce validation > before commit. This should probably be done by using NHibernate's > event system, to let NHhibernate call you validation logic right > before updating the database. Have you looked into this? > > Also, have you considered the alternative? I mean some kind of manual > keeping-track-of-stuff-that-must-be-updated? What problems would be > associated with that? > > /Oskar > > > > > On Aug 13, 12:42 am, Nelson <nelson.cab...@gmail.com> wrote: > >> On Aug 13, 6:55 am, Fabio Maulo <fabioma...@gmail.com> wrote: > > >> > Test case in uNhAddIns issues tracker, please.Aboutdirtychecking "In my > >> > opinion it should be an option disabled by default", thanks for your > >> > opinion > > >> You're welcome. I'm used to try to find an answer before asking > >> questions, which leads me to having opinions. > > >> > but it is one of the most useful feature of NHibernate. > > >> Thanks for yours. But it is also 'just an opinion', even if said in a > >> peremptory maneer. > > >> This features leads to unexpected and unobvious behaviour. If you > >> prefer to have it enabled by default, so be it, but users should > >> definitely be able to disable it if they want to control nhibernate > >> update behaviour. > >> I did not say it is an easy task, but you did not say why it must not > >> be disabled. > > >> > If you don't like AutoDirty check and the code in uNhAddIns does not > >> > cover > >> > exactly what you are looking for you are invited to share your failing > >> > test > >> > in :http://code.google.com/p/unhaddins/issues/list > > >> Shall I directly post it to NHibernate's JIRA in addition to that? > >> IT'S A BUG. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
