I've had to support a project using Fluent NHibernate for a few years now and I'm honestly tired of it. I want to use Dapper-dot-net (https://github.com/StackExchange/dapper-dot-net) going forward but some of my team is against using it due to the concerns of mixing two ORM frameworks into one project.
Are their concerns justified? Does anyone have experience in this area that could list why NHibernate and Dapper (or other ORM Frameworks) cannot exist together on the same project?
Thanks,
Firstly, I do not have direct experience of combining Fluent NHibernate (FNH) and Dapper in the same project so please bear that in mind! However I have used FNH, Entity Framework and Dapper independently in separate projects and, having chosen Dapper for the latest project precisely because of its simplicity and that I wanted to avoid a more heavyweight ORM, I can personally see the appeal of Dapper over more feature rich alternatives. Although there is no reason why the two can’t exist in the same project per se, I think your team are perfectly justified in raising objections about introducing another data access technology into the same project (however whether these concerns outweigh the advantages of moving to Dapper is of course dependent upon your teams' particular requirements).
Some immediate technical considerations/concerns that would spring to mind:
Mental context switching between a fully featured ORM, and a thin wrapper around ADO.NET. Although in trivial cases replacing:
Query(a => a.Id == id && a.Active == true)...
with
"WHERE id = @Id AND active = true"...
is not going to be a huge mental jump, I can understand that when debugging, switching between one query that uses FNH to another one that uses raw SQL and vice versa is probably not going to be the most pleasant experience for your team especially with more complex queries.
Do you plan on returning/consuming the same set of domain entities with your Dapper queries as at present? If so, are there going to be issues if you need to replicate functionality such as lazy loading (that you may be using currently but which won’t be provided in Dapper) and entity relations?
Dapper will obviously require you to hand write your SQL queries. If FNH was chosen because your team actively prefers writing LINQ style queries over raw SQL, or more importantly because they are not familiar with SQL, introducing Dapper will also force upon your team the learning curve of SQL.
Dapper will provide no compile time checking of your queries, so any changes to your entities that would normally be picked up in the fluent mappings and queries, which your team may be comfortable with and rely on, will not be flagged.
A more general concern would be how you plan to deal with a combination of the two in the longer term. I am not familiar with your particular project and how much FNH functionality you have employed so the following may be moot, however if you plan to use dapper going forward only, leaving your existing codebase as is, presumably you will need to retain someone who has expertise using FNH if complex queries making heavy use of FNH functionality ever need to be heavily refactored or debugged.