I think you're asking about Dapper (ORM) which could be compared to Entity Framework. The two major things to think about if comparing would be simplicity and speed. Dapper is simple to setup and use. It uses standard SQL and it's very fast. On the other hand, this is not a fair comparison. EF is has many more features and options. Use the right tool for the right job depending on requirements.
Elmah and NLog are not apples to apples either. Elmah make dealing with "Unhandled" exceptions very simple. Nlog is for application logging (Trace, Info) and exception management (A try catch scenario).
In fact it is not uncommon for me to use both Dapper and EF on the same project. Usually I'll use Dapper for the query/reporting side and EF for the domain model/update side. (Used to use nHibernate, but it seems to have really stagnated unfortunately)
Even then, for query building I found EF (or any LINQ provider for SQL) to be easier solution than string concatenation. Well, at least for relatively simple queries with pagination and stuff. For filters, Dynamic.Linq would be helpful here.
On the other side, if you need to work extensively with stored procedures or you have complicated or custom SQL to run, Dapper (or Insight.Database - https://github.com/jonwagner/Insight.Database, a library which I found really nice to use) will be your best friend.
It's true. What I really would like is a micro-orm like Dapper with support for using LINQ to dynamically build queries. But I suppose this is essentially EF with AsNoTracking, which I have yet to play around with and test performance wise.
AsNoTracking makes the materialization indeed faster, but EF always has a cost associated with it, both for initial use (set up of the context etc, which is noticeable) as well as every other query after that (expression tree parsing etc, not as noticeable especially for recurring queries).
I hope it's one of the pain points they will address and solve during their rewrite to EF7 at one point.
That being said, my opinion is that unless you have really strict performance and/or latency requirements, EF should be good enough. At least for simpler queries and in 'longer-running' applications :)
My testing showed that AsNoTracking is faster than dapper. But indeed the tests were purely focused on materialization and not query parsing: linq query parsing takes a lot of time, so with lots of predicates etc. you'll see much slower performance with EF compared to other ORMs with query systems other than Linq (except NHibernate, that's slow regardless)
Entity Framework isn't really similar to any of the things I listed. I tried to only include components you might use as part of a larger system, rather than technology stack choices.
Dapper distills the converting database rows to objects. It's a micro ORM, which means it doesn't try to abstract SQL like a monolithic ORM (NHibernate, EntityFramework) would do. Example:
public TagModel GetTag(long id)
{
using (var conn = m_connector.GetConnection())
{
return conn.Query<TagModel>("SELECT TOP 1 * FROM Tags WHERE Id = @Id", new { Id = id }).FirstOrDefault();
}
}
AutoMapper does not really compare to EF. AutoMapper is used to copy automatically data between two objects of different classes (like a.UtilisateurName = b.Utilisateur.Name). It uses Reflection for that. I will try to link automatically properties by their names. The two classes do not have to have the same format. It works if one the classes is the flattened version of the other.
We use Elmah instead of Nlog, which is also fine. Looks like NLog is a bit more flexible than Elmah is. But Elmah is KISS which is nice.