Background

Although I’m a fan of the repository pattern, Entity Framework is very performant and convenient. Especially with the efficiency enhancements in the Core editions.

In the ideal world I’d have a repository but I’d like the convenience of EF doing a lot of the heavy lifting. EF for example is very good at change tracking, or mapping between class properties and database columns.

What I often do therefore is have a repository which uses an EF Core context to do the work.

This way I get strongly typed and narrowly defined repositories, yet with great flexibility behind the scenes.

How I generate my EF Core contexts

For all the good stuff that DotNet Core has brought in, with Visual Studio I still get regular issues. One of the main ones is with scaffolding and migrations.

Usually they work perfectly at the start. Then as things get more complex they begin to stop working.

Which brings me to Newt - source

It’s a simple Core console app that will scan a Postgres database and create code. The output is a project containing:

• entities for each table found
• contexts for both InMemory and Postgres
• a fallback SQL script to recreate the tables

It should be noted that the SQL generated in that fallback script is not complete. Designed for emergencies, it only recreates the basic tables and column details.

The context and entities generated can be used directly from other projects as usual. Or you can try sticking a repository in front of them.

Either way, it’s a fast and simple way to get a nice, clear context to work with.