Simple.Data, is it really a good idea?

I've been keeping an eye on micro ORMs for a while. Yesterday I decided to give Simple.Data a try. From the introduction, it looks brilliant, the fluent API, the briefness, the simplicity,..., everything seems to be perfect... well, until I started coding.

Once I'm in VS, I immediately realized that Simple.Data might not be the one I wanted. Its magical syntax heavily depends on .NET's new dynamic feature (yes, it's .NET 4 and above only). That means you loose the static language's best capability: compile time checking. And also you loose the productivity from your tool, there is almost no intellisense provided by VS. You might say, what's the big deal, the syntax is cool. Yes, it's cool. But the problem is, if you make an accident typing or a normal typo (who doesn't?), then compiler won't be there for you and you'll only get the null at runtime. Maybe through unit test coverage may resolve this. But from where I stand, it seems to be just a better alternative of HQL dressed with a new cloth named fluent API.

But I did find some part that really make me happy. It seems Simple.Data recognizes fields separated by underscore. I've got a table with columns like CUSTOMER_ID, and Simple.Data can happily map it to a property named CustomerId. If I rename CUSTOMERID, then Simple.Data still works fine. This is clever!

There is a tool, Simple.Data.Pad, to address this issue. So far I haven't been able to make it work with sqlite yet.

In general, I'm not so convinced yet, but I'll continue on the project to work with it, let's see where I'm going to end with.