http://d4dilip.wordpress.com/2011/09/27/user-nhibernate-with-legacy-database/

However, I must say that I like the idea of the views as proposed by Alan as well: overall performance will be better in the end, and the creation of a view on a single database table is a relative simple operation. In my experience, legacy databases also often tend to have cryptic column names etc., and you could take the occasion to name fields on the views such that mapping in e.g. FluentHibernate becomes more convention based …

The approach I eventually settled was to isolate the database with using the Interface Segregation Principle implemented with Views. Create a SQL View that bridges the gap between what your Domain cares about and the realities of the database. For Inserts/Updates, you can either use Updatable Views or Stored Procedures to handle the default data. Updatable Views are a little cleaner because NHibernate sees it as a table and no extra mapping is required. I realize that you’re shifting the complexity out of the code and NHibernate into having to write some SQL. But it seems a cleaner solution to me. An additional benefit is hopefully someday the legacy application will go away and the views will eventually be replaced by actual schema and you can keep your mappings and just change the table name.

In the event that these legacy issues present themselves on all your tables I might be more inclinded to follow your approach. Writing a significant amount SQL means you lose the advantages of NHibernate.

I once worked at a place where objects actually maintained their own population and persistence methods internally. It was ridiculous to maintain once you needed to work with an object in even a shred of a way different than it was originally created for.