Peter Bromberg's UnBlog

“I'm thirty years old, but I read at the thirty-four-year-old level.”   - Dana Carvey Recently I participated in a Twittervation (“Twitter conversation”?) that started with a respected friend, who is a very well-known MVP, book author, and article writer, complaining that Entity Framework was a “pain in the ass”. That was “out of the blue”, it wasn’t in response to somebody else’s tweet. Of course, I felt compelled to respond and tweeted, “NHibernate. Also PITA, but without all the MS data-centric baggage. (Just my 2 cents)”. Almost simultaneously, another MVP friend of mine who has a follower relationship with the first Tweeter and me said, “why not use NHibernate?”. Subsequent Tweets revolved around “Don't get me wrong, not saying you shouldn't use it or that you're wrong for doing so. Just asking if you've seen NH”, and my ending with “I did a lot of research, man. It was painful. NHibernate won. End of story.” Why did I say this? I have no beef with ...

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 POCO s (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 the...