Peter Bromberg's UnBlog

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...

People demand freedom of speech as a compensation for the freedom of thought which they seldom use . – Soren Kirkegaard In the process of stumbling through LINQ To SQL to see if I would be able to represent a SQL Server database schema I created to provide storage for a hierarchical well-defined XML Schema for a commonly used utility object, I came to the realization that I was indeed doing everything completely backwards ! What I am saying is this:  ORM should be done by focusing on the OBJECTS FIRST, not the Database Schema! Unfortunately, most of the tools we have are data-centric, not object-centric.  Scott Allen has a post that clearly describes the debacle . To my knowledge, there will not be any plain old CLR objects (POCOs) in Entity Framework. LINQ to SQL doesn’t yet have all the mapping capability to really separate the object model from the underlying database schema – and of course, you can use it with SQL Server only. Now, this situation may imp...