nhibernate.config vs web.config

I currently have an ASP.NET MVC project built on top of the S#arp architecture and NHibernate. I currently have a separate nhibernate.config file for my nhibernate configuration. I am considering moving it to web.config instead as I want to be able to update my nhibernate configuration and for it to (effectively) take effect immediately. There are a number of other ways I could achieve this, ranging from simply recycling the app pool after making my change to using the FileSystemWatcher class to detect changes to nhibernate.config. I think moving the configuration to web.config is the simplest however.

I think the only benefit of having the nhibernate configuration in it's own file is that it keeps your configuration a little more modularized. I don't really see this as a huge benefit however.

Are there any other benefits to having your configuration separated like this that I am missing? Are there any downsides to putting the nhibernate configuration in web.config that I haven't considered?

I have searched for arguments either way and can't find any. Some tutorials/articles use a separate config file and others use web.config.

EDIT: Response to @Jamie Ide's question

The开发者_StackOverflow社区 main thing I want to achieve is switching second level caching on and off. I'm using AppFabric for my second level cache and the only way I can find to clear out or expire the cache manually is to restart the cache cluster. My code handles AppFabric being unavailable but the exception the app fabric client throws takes a very long time to be thrown, so my site is not particularly responsive during the (roughly) two minutes or so it takes the cluster to restart. I think it would be better to simply switch off second level cache, restart and then switch it back on again. I understand that updating the configuration will require a restart, but this should happen when I edit web.config - I just don't want to have to do the restart manually as well.

I think the only benefit of having the nhibernate configuration in it's own file is that it keeps your configuration a little more modularized. I don't really see this as a huge benefit however.

I think that's a pretty big benefit and a good reason to keep them separate, but Web.config has been considerably slimmed down so it's not as compelling a reason as it used to be. The SessionFactory is usually built using configuration at startup so making NHibernate configuration changes will require an application re-start anyway. What changes do you need to make on-the-fly?

You are right in all the ways you have thought and weighed. Separate nHibernate config is there just to keep verbose configuration out of normal web.config. Merging it into web.config will give you obvious benefits and no side effects.