I have a couple of projects coming up and I am trying to decide on a persistence framework to use. I pretty much narrowed the scope down to NHibernate and Fluent NHibernate, Linq2Sql, or Entity Framework 4.0 (there really on 4.0? really?). So far here is my 'superficial' thoughts, feelings about each (note that until I actually commit to one I won't truly understand it's benefits and/or limitations):

1. NHibernate/Fluent Nhibernate
   1.  Yeas
      1. Cleanly separates persistence layer from domain layer - you can pretty much ignore the database
      2. Strong adoption amongst the 'in-crowd' - many, many Alt.Net and .NET bloggers/developers profess to it's prowess (Ayende, etc)
      3. Supposed strong community
      4. Very configurable - lots of OSS extensions, etc.
   2. Nays
      1. Lack of centralized ownership (IMO) - no single contributer/owner, lots of work outside the main trunk 
      2. Documentation is all over the place; some of it does not seem to be written clearly or lacks steps that require some amount of presupposed knowledge of NHibernate or one of it's dependencies
      3. No support from any of the larger software dev companies
      4. From the main source forge site I don't see much activity; i see more spam that has _not_ been removed than new members.
      5. First implementor syndrome?
2. Linq2Sql
   1. Yeas
      1. Super simple, limited functionality ORM
      2. Used it, know it, no surprises
      3. Tons of documentation, blog entries, SEO fodder content...everyone has had a turn 
      4. Write code while others configure...
   2. Nays
      1. Obsolete - MS is moving to Entity Framework
      2. Minimalist ORM - you end up adding additional features (such as caching) - this could be a strong point as well
      3. Poor performance with many concurrent users until you optimize (which is relatively easy: compiled queries, etc)
3. Entity Framework 4.0 
   1. Yeas
      1. Strong MS commitment (or so it seems, unless they have another MS Research project that cannibalizes on this one)
      2. Lots of current documentation
      3. Centralized community (well MS...)
      4. Seems like the have addressed the shortcomings of Entity Framework 3.0 - I won't really know until I commit to using it, the truth always comes out in the implementation
   2. Nays
      1. Previous versions of Entity Framework were horrible
      2. YAMSOSFAS - Yet another Microsoft one size fits all solution
      3. Trust - MS seems to jump from one thing to the next - outside the grokking of us mere mortals; what they support monday might be obsolete on tuesday.
      4. Personal - I always either build it myself or fall back to MS; I need some new experiances ;)
      5. I have worries about the how easy it is to break away from the MS model of horrible code generation experiences. I have seen enough MS brochureware to make me sick for life. I need real world flexibility with MY model, domain, etc. not what MS marketing deems significant.

So that is my initial, superficial perception of each persistence framework. Next up is looking into more specific and less subjective reasons for liking or disliking each ORM solution.

If you do any work with xml you probably have come across scenarios where you are using an XmlWriter to produce an output stream of xml. Eventually this output stream is either persisted to disk via an XDocument, sent over the wire using a distributed technology such as WCF, Remoting etc., or possibly transformed with XSL/XSLT. A strong example is custom serialization classes that implement IXmlSerializable.  For example:

The class above is a simple data transfer class (DTO) that implements IXmlSerializable so that it can be serialized and/or deserialized from an objet to an xml stream and vice versa. Note: in most cases you would simple mark the class as [Serializable] and/or provide attributes from the System.Xml namespace to provide the same behavior, however in many cases the default implemention will not fit your particular scenario, hence you would implement IXmlSeriable and provide your own custom serialization.

Here is the 'custom' serialization implementation:

While the XmlWriter/XmlReader API's are pretty simple to use, they are also a bit verbose. If you happen to have a fairly large class with many fields, things start to get ugly pretty fast. Typically when I see large classes, I began to think about refactoring into smaller classes when applicable, but that not always the case. Since, most of them time when want serialization/deserialization you simple want to quickly (i.e. less keystrokes) turn the contents and structure of the class into its xml equivalent you are looking at reducing the amount of work needed. This is where extension methods really come in handy:

The result compared to above is a much cleaner, easier to read class:

While extension methods are not new, they do offer unique way of handling situations where you would like to simplify a set of operations without reaching for the traditional static xxxUtil class or creating a customized implementation or wrapper class. In this case,  XmlWriter is a class open for extension via basic inheritance, unlike a sealed class such as System.String, which is the intended purpose of extension methods: extended classes closed to inheritance (sealed).