Podcast:
Hanselminutes: The Rise of the Micro-ORM with Sam Saffron and Rob Conery
dapper-dot-net - Simple SQL object mapper for SQL Server - Google Project Hosting
Massive by Rob Conery @ GitHub
Performance of SELECT mapping over 500 iterations (from Dapper's web page)
Method | Duration Static | Dynamic
Hand coded, SqlDataReader | 47ms | -
Dapper | 49ms | 52ms
Massive | - | 52ms
SubSonic | 107ms | 3619ms
NHibernate SQL | 104ms | 118ms
Linq 2 SQL | 181ms (static), 559ms
Entity Framework | 631ms | 859ms
SqlDataReader is "old" technology, a lot of code... but FAST
Linq 2 SQL was "new" 2 years ago, now is "old"
Entity Framework (EF) is "hot new"... by Microsoft
NHibernate is popular open-source...
Massive is total of only 364 lines of code, Done by a single person (ex-Microsoft)
The key "feature" is use of dynamic "ExpandoObjects" from .NET 4.0, instead of "proxy" classes that are typically created by ORM tools for each db table. It is not the same, since without proxy class there is no IntelliSense.
This makes C# closer to Ruby, as author intended.
And since it is dealing with direct SQL queries, performance is very good.
Dapper is developed and used for hugely popular web site Stack Overflow.
The performance is key in this case. StackOveflow was able to become
one of most popular sites on web running on only one server, much later on total 3 servers! 4-10 times faster data access is a big deal in that case.
While ORM's raw speed is important, API syntax and developers productivity is also,
and both LINQ and EF are very convenient to use, making developers productive.
In fact, most of .NET developers use "binding" of UI components to data source,
not even observing data access... and many times sacrificing performance.
I have created and used similar wrappers of SqlDataReaders,
this is a universal need... It would be worthwhile to have a test platform
for measuring and comparing both usability and performance of alternative
data access approaches, including various NoSQL solutions.
Microsoft currently has a huge focus on EF... hope they will tune the speed also,
since 10x slower (if we can trust reports) may be too big performance price for API convenience.
No comments:
Post a Comment