Except... and this is just as important... I did something similar and when I checked SQL profiler NHibernate was submitting a single delete for every related object in the collection. This wasn't very performance friendly. You could put the rule in the mapping file to cascade the deletes but, as stated, this (a) bleeds NHibernate control into the domain layer and (b) doesn't actually make any difference as regards performance anyway (NHibernate still did the single deletes).
What I had to do to get the performance was to set my mapping file to cascade (e.g. on-delete="cascade") and then enforce this in my database through referential integrity. Not ideal I know, but I've seen apps killed by not focusing on performance to some degree when creating the NHibernate mappings. As regards persistance ignorance, you can argue that by relying on implict Lazy Loading you bleed NHibernate (or Linq-SQL as that supports Lazy Loading if you chose that) into your domain layer as now you can't swap out for Entity Framework that does not support implicit Lazy Loading, or any other repository implementation without Lazy Load (e.g. Raw ADO.NET). When you swap out all that nice business logic property navigation you do will blow up in your face due to null exceptions. My point is that true PI does not exist, so make the compromises where you need to (and as few times as you need to) but don't stress too much about it when you do. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
