One issue I don't understand using NHibernate is what effect it has (at least if using "best practices" in an ASP environment) on the separation of data manipulation logic from data access logic.

Forgive me if this question sounds stupid, but I'm a client/server guy with little ASP experience. From what I've read about ideally keeping things stateless, and from what others on my design team are saying, any code that modifies data must also submit that data back to the data access layer (if there is one, else to NHibernate directly) to be saved, in the very same method. Otherwise, entity objects (or your own gateway / data access layer) must keep track of what objects are changed or marked for deletion. I'm having a hard time seeing how this is a good idea, since it forces every piece of code that could change a value to persist it immediately. Doesn't this destroy good object-oriented division of responsibility? It seems to prevent the use of any services that aren't aware of your specific DAL.

All I can say is that "best practices" can not be applied "as-is" in every case.
You should choose the design which best fit with your goals...

Just because the web is stateless doesn't mean you can't maintain state. You can save your business object in session or viewstate and also maintain it's state (new/updated/etc). This would persist thought several postbacks if needed and only submit to the DAL when the business transaction is completed.

Otherwise, how would you keep the business transaction ATOMIC if you are submitting to the DAL on every modification or state change?

BOb

Our development lead is currently insisting that all our pages be stateless. He said we had such bad experiences trying to keep state in the past that we must not keep any state in our next product.

Apparently then all entity objects are disposed after the page is rendered, and new instances of them must be created when it comes time to postback? That sounds like a major hassle to somehow reconstruct the entities from raw bound scalar values from a grid, rather than simply deserializing cached objects. Am I understanding the consequences of this correctly?