anchor.diff:  - FSharp/LINQ query-syntax is a learning curve
   - Doesn't generate domain model for work with C#
   - Most LINQ-operations supported, but not yet complex group-by scenarios
  +- Updates in complex scenarios can be a pain
   
   ### SqlDataConnection
   
  
positive.code: [Dapper](https://code.google.com/p/dapper-dot-net/)
  -----------------------------------------
  
  FSharp.Data.SqlClient is much closer to the family of micro-ORMs rather than complete solutions like EntityFramework and NHibernate, 
  hence comparison with the best of the breed - Dapper.
  
  Dapper is a micro-ORM by StackOverflow with a main goal of being extremely fast. Here is a [description](http://stackoverflow.com/tags/dapper/info) 
  from StackOverflow itself:
  
  >dapper is a micro-ORM, offering core parameterization and materialization services, but (by design) not the full breadth of services that you might 
  expect in a full ORM such as LINQ-to-SQL or Entity Framework. Instead, it focuses on making the materialization as fast as possible, with no overheads 
  from things like identity managers - just "run this query and give me the (typed) data".
  
  Let's start with performance to get it out of the way. 
  
  Dapper comes with an excellent [benchmark](https://code.google.com/p/dapper-dot-net/source/browse/Tests/PerformanceTests.cs). 
  The focus of the test is on deserialization. Here is how FSHarp.Data.SqlClient compares with all major .Net ORMs:
  
  <img src="img/dapper.png"/>
  
  Tests were executed against SqlExpress 2012 so the numbers are a bit higher than what you can see on 
  [Dapper page](https://github.com/SamSaffron/dapper-dot-net#performance-of-select-mapping-over-500-iterations---poco-serialization).
  A test retrieves single record with 13 properties by random id 500 times and deserializes it. Runs for different ORMs are mixed up randomly. 
  All executions are synchronous.
  
  Note that we didn't put any specific effort into improving FSharp.Data.SqlClient performance for this test. The very nature of type providers helps to produce
  
negative.code: A comparison on SQL Server data access methods
  ==============================================
  
  Type providers + Query Expressions
  -----------------------------------------
  
   F# Query Expressions (aka LINQ 2.0) is lovely and useful technology. It makes writing data access code a pleasant exercise.
   There are several different implementations available: [SQLProvider][sql] (recent community effort), [SqlDataConnection][linq2sql]/[DbmlFile][dbml]
   and [SqlEntityConnection][ef]/[EdmxFile][edmx].
  
   But I would like to point out some reasons you might prefer SqlCommandProvider over those.
   Take a look at this  [StackOverflow issue][soissue]. There are dozens of similar questions (hundreds if you include C# LINQ which is essentially
   the same issue).
  
   So, what's a deal? The thing is, you can have perfectly valid F# code that compiles but still fails at run-time because of
   unsupported F#-to-SQL translation semantics. Contrary, SqlCommandProvider offers "What You See Is What You Get" approach.
   Once F# code involving SqlCommandProvider passes compilation stage you are guaranteed to have valid executable (both F# code and T-SQL).
  
   Lack of control and opaqueness of F#-to-SQL conversion spells performance problems too.
   At times developers are really frustrated by ineffective T-SQL code generated by type providers (most of EF users are aware of this issue).
   Evolution and changes in T-SQL code generated by type provider may present certain problems too.
   A data access code that is performing well today can become suboptimal tomorrow.
   SqlCommandProvider gives you direct access to full power of T-SQL scripting including the latest features which are often
   unavailable in type providers because they target older or different versions of the system.
  
     [sql]: http://github.com/fsprojects/SQLProvider
     [linq2sql]: http://msdn.microsoft.com/en-us/library/hh361033.aspx
     [dbml]: http://msdn.microsoft.com/en-us/library/hh361039.aspx
  