Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
NetCore data access strategy: resolving EF blockers #96
In order to move to .NET Core we need to replace our EF 6 data access strategy with a .NET Core compatible solution.
EF Core 2
When looking at EF Core 2 there still seems to be some features missing that we make use of, mainly support for GroupBy queries. Some investigation is required here to see how compatible our use of EF 6 is with EF Core. Even if we do drop EF use within Cofoundry, we'd certainly want an EF integration package to provide a DbContext to developers who prefer to work with EF.
It could be that we simply use stored procs for certain queries to get around missing features in EF Core.
Currently we only support MS SqlServer. We haven't had feedback to say that other database support is required, and I don't think we'd ever want to have a broad range of DB options but I could see supporting something like postgres may be popular. However being able to target a single database allows us to optimize for that platform which I feel is an advantage compared to being restricted to the lowest common denominator.
Using an ORM like EF does give us flexibility in the underlying db platform, but our migrations, stored procs and other db objects still tie us to SqlServer. Unless we hear reasons otherwise, I'd like to move forward with a single database platform strategy targeting only MS SqlServer.
Dapper is an obvious candidate that needs researching. I've always thought that we'd move towards stored procs for data access as part of the optimization process so a lighter ORM would be in line with that thinking.
I'm also keen to remove our dependency on AutoMapper for mapping database data to domain models, mainly because it's a popular tool and our internal use can conflict with an implementation in unpredictable ways. So I'd also want to look at how we materialize those domain objects as part of this too.
Some other features to keep in mind:
I've migrated to use EF Core. Some queries that use GroupBy suffer from in-memory materialization of the grouping, but this isn't show-stopping at typical loads and can be optimized with a bit of work. Our two main EF issues will remain unfixed in EF Core 2:
We'll come back and revisit this after we are up and running in .net core and assess our options.
The AutoMapper dependency has now been removed. EF still remains but to get around issues we've restructured some queries to remove the need to use groupings.
Although the question of using EF as a data access strategy long term still remains, I think for now it is working well enough to use for the net core release.