I don't like it, and we don't use it at Fog Creek, but, yes, it's VERY heavily used on piles of projects I know. It's not as efficient or flexible as NHibernate, but it's far easier and vastly better integrated into Visual Studio, making it a bit of a no-brainer for simple persistence needs.
So, what do you guys use at Fog Creek. I've been discussing with my colleagues some of the micro-ORMs like Dapper, Massive, or PetaPoco as an alternative to EF.
Just to give my 2c, EF is not so much an alternative to Dapper/Massive/PetaPoco as an alternative to NHibernate.
Both are "heavy-duty" orms, while those 3 are more lightweight. My personal view is that for writes and maintaining a domain model, NH (or EF, but I prefer NH) is a good option, and when you need performance or just want a light layer to ease the mappings from sql to objects, micro-orms are the best option.
I don't know what they use at Fog Creek, but I will say that I've been building a lot of things lately in both Massive and PetaPoco, and I've really enjoyed it. I've done several projects in both Linq2SQL and EntityFramework at this point, and they both seem way too 'heavy.' Writing straight sql (or pretty much straight sql) has been a return to simplicity. it's forced me to make sure my queries are efficient, and only return what they need to return.
I do miss using Linq to query the db, but not enough to make me go back. I use EF in my main job, and while it does the job, sometimes I find myself being constrained by the framework. That's not an issue with EF so much as it is an issue with any kind of ORM.
PetaPoco has been excellent so far. I really like being able to easily switch between dynamic and strongly typed results. If you're not doing "Select * on <table>" the dynamic result is pretty necessary.
I do see where there could be some ways to improve querying the database where you're doing a lot of joins or returning data that is not limited to the table design at all.
Kiln uses LINQ to SQL and Dapper, for the same reasons StackOverflow does: the combination combines speed with flexibility. We expect to ditch one or both in the medium future (we want to support more than just SQL Server), but it's a good fit for the moment.
