Nhibernate Fluent => hbm => SQL Schema

What luck for rulers that men do not think.  - Adolf Hitler

More experimentation with NHibernate and we’re getting very close to Nirvana. The concept is (once again) – let’s develop our domain model first (similar to the “contract first” paradigm with SOA and WebServices) , create the mappings, and then create the database schema for the persistence mechanism (SQL Server, whatever) last.

The Fluent.NHibernate project  API allows you to map entities in NHibernate in a more expressive and more testable manner than you are typically able to do. What it does is to give you a clear path to take your POCOs (Plain Old CLR Objects) –- without any of the “glop”  attributes or dependencies – just standalone objects – and turn them into NHibernate  .hbm XML Mapping files. This is very cool because it means your objects can be marked [Serializable] and you can send them over the wire via WCF, etc. without the – “[VendorNameHere] Baggage?” getting in your way, because they don’t really have any.

Once this is accomplished, you can use the built-in NHibernate Tools classes to create an actual SQL Server (or other RDBMS) Schema SQL script to generate the database tables that mirror what your domain model represents in your POCO code.

Additionally, the Automap Classes are moving closer and closer to the ability to take care of the mapping “all at once” with a single method call. You don’t even need to persist .hbm XML mapping files; the NHibernate runtime is capable of using the generated mappings in memory.

Again, the whole point of this exercise is “Top Down” or “Objects First” – this flies against the face of the Microsoft Data-Centric approach of “Database first” LINQ-to-SQL or Entity Framework development (which is not a bad thing, because it is eminently usable) and will require further study by developers who understand the concept of “clean, unadulterated POCOs” that represent a true Domain Model approach to solving business problems for clients.

I’ll post more on this and probably write a comprehensive article to be posted on our eggheadcafe.com site complete with a downloadable VS 2008 solution.

Comments

  1. Anonymous6:52 AM

    Peter, Great post. I think this is definitely the way to go in regards to building applications nowadays. The one area that I see most new developers having problems with is "Where do I store my data when I need to test the app then." Trying to get them to shift paradigms in regards to that is sometimes difficult. When drafting your eggheadcafe post, be sure to include a little snippet about that! Again, great post.

    ReplyDelete
  2. Anonymous1:11 PM

    http://martinfowler.com/bliki/FirstLaw.html

    ReplyDelete
  3. OK, Anonymous.
    Fowler has a lot to say about cross-process ("remoting") calls in his first law, but I fail to see how this relates to NHibernate Auto-mapping.

    ReplyDelete
  4. Martin is saying don't shuttle your domain objects across the wire. Instead you want to make calls across the wire. Better yet, you want to send "domain events" across. Once you start distributing your objects, you're in for a world of hurt.

    ReplyDelete

Post a Comment

Popular posts from this blog

Some observations on Script Callbacks, "AJAX", "ATLAS" "AHAB" and where it's all going.

IE7 - Vista: "Internet Explorer has stopped Working"

FIREFOX / IE Word-Wrap, Word-Break, TABLES FIX

System.Web.Caching.Cache, HttpRuntime.Cache, and IIS Recycles

FIX: Requested Registry Access is not allowed (Visual Studio 2008)