NHibernate - does it work well with database-level cascading deletions on foreign key constraints

Dose nHibernate play well with database level cascading deletions? What I mean is that if I have a cons开发者_如何学运维traint set at the RDBMS level to cascade delete all orphans, will nHibernate invoke any custom delete logic at the application level if I were to delete an entity though nHibernate? Or should I remove the cascading deletions from the RDBMS level and just use the cascading delete feature of nHibernate itself by defining that behavior though its configuration?

Thanks

NHibernate simply treats your RDBMS as a data store. In most cases, this means that you can let NHibernate do the work for you.

Let NHibernate do the cascading deletes. That way you can keep your logic and control where it belongs (in your application), rather than in the database where your application has little control or flexibility.

EDIT:

ON DELETE CASCADE does not always exhibit great performance with NHibernate. You have to be very careful what the cascade settings of your collection associations are set to. See this article: http://eddii.wordpress.com/2006/11/16/hibernate-on-deletecascade-performance/

Unless performance is a big issue for you, it's generally cleaner and less problematic to let NHibernate do the work. Jamie Ide correctly points out:

As with triggers, NHibernate will not know that the database representation of an object has changed due to a database operation. I would avoid using them for this reason in most cases.

It can work with database level cascades. You can declare them in the mapping, so the hbm2ddl tool will generate the on delete cascade. The option is in the collection's key property.

<bag ...>
    <key column="someId" on-delete="cascade" />
...
</bag>

It depends what you mean by "play well". You can use cascading deletes with NHibernate but you need to be careful to refresh objects that may be affected by cascading deletes. As with triggers, NHibernate will not know that the database representation of an object has changed due to a database operation. I would avoid using them for this reason in most cases.