* I seem to install Json.net in every .NET project I create (json serializer - thanks James Newton-King!)
* NLog for logging. It's fantastic.
* Dapper is also excellent (Micro ORM) (and anything written by Marc Gravell is generally top-notch - see protobuf-net, miniprofiler, StackExchange.Redis)
* Automapper, to avoid writing boilerplate code to convert between similarly shaped types (E.G. DTOs to DB models).
* RestSharp makes talking to RESTful apis easier.
* Microsoft's Unity is a great IOC framework, although most people seem to use NInject.
Excellent list. Another addition I would make is another contribution from Stack Exchange, this time from Kevin Montrose. It's a high-performance JSON serializer/deserializer called Jil. https://github.com/kevin-montrose/Jil
I've been using it on most of my newer projects this year and I have to say I much prefer it over the (still excellent) Json.net.
> * Microsoft's Unity is a great IOC framework, although most people seem to use NInject
Autofac is my favorite. Once built, containers are immutable, there is deterministic disposal of components in 'lifetime scopes', and delegate factories make it much easier to instantiate classes with a mixture of services and data.
Dapper is a really awesome library when you want to write complex queries (full of table hints, output clauses, merges and other advanced stuff), but don't want to write enormous amount of code for adding parameters and reading result sets.
I've also used BLToolkit, and it is pretty fast too, plus it has Linq support to build strongly-typed queries that sometimes better than raw SQL queries. But when it comes to table hints, Linq and other stuff does not help. So, it always depends :)
Damn, thanks for pointing me in that direction. It's exactly what I've been looking for.
Technically, I implemented some of that stuff myself because I needed REST client that would work with PCLs and be a bit 'nicer' to use than just juggling strings/routes everywhere, so using annotations and wrapping Microsoft's HttpClient was obvious and relatively easy way out.
Anyway, I'll probably just phase out my own solution and start using the library.
[EDIT]
After checking it out, RefitStubs.cs file seems a little bit clunky, but the library as a whole looks solid enough. I'll look further into it.
RefitStubs is necessary because on certain platforms (iOS, WinRT), you cannot JIT and therefore can't use something like Castle Core to generate a class
On the other hand, I wonder if it wouldn't be easier to ship a T4 template? I know for sure that would integrate with VS (both the IDE and build process) without any issues, not sure about Xamarin Studio...
I'd add ImageResizer for resizing images ( and in MVC resizing them in a restfull way...). You can also localcache them or cache external images (resized). You can also store them in the cloud and add effects to the images.
I use NLog, but I access it through the Common.Logging facade. This is helpful when I need to bolt my code into an environment where NLog kind of sucks, like Xamarin.Android.
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.
* I seem to install Json.net in every .NET project I create (json serializer - thanks James Newton-King!)
* NLog for logging. It's fantastic.
* Dapper is also excellent (Micro ORM) (and anything written by Marc Gravell is generally top-notch - see protobuf-net, miniprofiler, StackExchange.Redis)
* Automapper, to avoid writing boilerplate code to convert between similarly shaped types (E.G. DTOs to DB models).
* RestSharp makes talking to RESTful apis easier.
* Microsoft's Unity is a great IOC framework, although most people seem to use NInject.