Boost Your EF Core Productivity in PostgreSQL With Entity Developer

A kitchen recipe card box

Imagine your grandmother keeps a small wooden box full of recipe cards. Each card has a dish name, the ingredients, and the steps. When she wants a new dish, she writes a fresh card by hand. When she changes a recipe, she rubs out the old line and writes the new one.

This works, but it is slow. If she has a hundred cards and decides every card should also show the cooking time, she must pull out all hundred cards and add that one line to each. That is a lot of careful, boring writing.

Now imagine a helpful machine. You tell the machine, "I want a card for Paneer Butter Masala, with these ingredients." The machine prints a neat, perfect card for you. If you say, "add cooking time to every card," the machine reprints all of them in seconds, exactly the same style every time.

Entity Developer is that helpful machine for your database code. Instead of writing every entity class and mapping by hand in EF Core, you draw your model on a picture (a diagram), and the tool prints the C# code for you. Change the picture, and it reprints the code. That is the whole idea, and the rest of this article shows how it works with PostgreSQL.

What problem are we solving?

When you use Entity Framework Core (EF Core) with PostgreSQL, you usually write classes like Customer, Order, and Product by hand. You also write a DbContext and lots of configuration. For a small app this is fine. For a big app with fifty tables, it becomes a mountain of typing, and small mistakes creep in.

EF Core, unlike the older classic Entity Framework, has no built-in visual designer inside Visual Studio. You cannot draw your tables and let the IDE make the code. This is exactly the gap Entity Developer (made by a company called Devart) fills.

Here is the high-level idea in one picture.

The arrows go both ways on purpose. You can start from the database and make the model, or start from the model and make the database. We will cover both.

Three ways people build EF Core models

Before Entity Developer, let us name the common approaches. This helps you see where the tool fits.

Plain EF Core supports Code-First and a basic scaffolding for Database-First. It does not give you a friendly Model-First diagram. Entity Developer adds a real visual designer, so you get Database-First and Model-First, and you can even mix them.

Setting up: what you need

To follow along you need a few things. Nothing here is hard.

1. PostgreSQL installed, or a connection to one (even a free cloud one).
2. .NET 10 SDK (the current LTS release) so your project can run EF Core.
3. Entity Developer from Devart. You can use the standalone app or the Visual Studio add-in.
4. The PostgreSQL EF Core provider in your project. The popular one is Npgsql.EntityFrameworkCore.PostgreSQL, and Devart also ships its own dotConnect for PostgreSQL provider.

A normal EF Core PostgreSQL project file looks like this. Entity Developer will generate code that fits right into it.

// Program.cs — wiring EF Core to PostgreSQL
using Microsoft.EntityFrameworkCore;
 
var builder = WebApplication.CreateBuilder(args);
 
builder.Services.AddDbContext<ShopDbContext>(options =>
    options.UseNpgsql(
        builder.Configuration.GetConnectionString("Shop")));
 
var app = builder.Build();
app.Run();

The ShopDbContext and the entity classes inside it are what Entity Developer creates for you. Let us see how.

Path 1: Database-First (you already have tables)

Say your team already has a PostgreSQL database called shop with tables customers, orders, and products. You do not want to retype all of that as C# by hand.

With Entity Developer the steps are short and visual.

When you connect, the Database Explorer window lists every table and view. You drag the ones you want onto the diagram. Entity Developer reads the columns, the primary keys, and the foreign keys, and it draws the relationships for you. An order's link to a customer shows up as a line on the diagram, not as code you must remember to write.

The generated entity might look like this.

// Generated by Entity Developer from the "customers" table
public partial class Customer
{
    public Guid Id { get; set; }          // maps to uuid
    public string Name { get; set; } = "";
    public string Email { get; set; } = "";
    public List<Order> Orders { get; set; } = new();
}

Notice the Guid Id. PostgreSQL has a native UUID type, and Entity Developer maps it to a C# Guid automatically. You did not have to know the exact mapping rule. That is the time-saver.

Keeping the model and database in sync

Databases change. Someone adds a phone column to customers. In plain EF Core you would re-scaffold or hand-edit. In Entity Developer you run Update From Database, and the new column appears on your entity. If instead you changed the model and want the database to catch up, you run Update To Database. Both directions, any time.

Path 2: Model-First (no database yet)

Sometimes you start with an idea, not a database. You want to design first and create tables later. This is Model-First, and it is where the visual designer really shines.

You open a blank diagram. You add an entity called Product. You add properties: Id, Name, Price, Tags. You draw a line from Product to Category to show "a product belongs to a category." No SQL yet, no C# yet — just a clear picture.

When the picture is ready, Entity Developer does two things. It generates the C# code (entities + DbContext), and it can generate the database script (the CREATE TABLE statements) to build those tables in PostgreSQL. You went from idea to working database without writing the boring parts.

How code generation works (T4 templates)

The "printing machine" inside Entity Developer is powered by T4 templates. A template is a recipe that says, "for each entity, write a class with these properties and this style." Entity Developer ships with ready-made templates, so you get good code on day one.

// Example of generated DbContext (shortened)
public partial class ShopDbContext : DbContext
{
    public ShopDbContext(DbContextOptions<ShopDbContext> options)
        : base(options) { }
 
    public DbSet<Customer> Customers => Set<Customer>();
    public DbSet<Order> Orders => Set<Order>();
    public DbSet<Product> Products => Set<Product>();
 
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // Mapping code is generated from your diagram
        modelBuilder.Entity<Customer>()
            .HasMany(c => c.Orders)
            .WithOne(o => o.Customer);
    }
}

Because the templates are just files, you can edit them (in the paid editions) to match your team's style. Want every class to be sealed? Want a particular naming rule? Change the template once, and every generated class follows it. This is the same benefit as our recipe machine reprinting all the cards in one style.

PostgreSQL features Entity Developer understands

PostgreSQL is not just plain tables. It has special column types that EF Core can use, and Entity Developer knows how to map them. This matters because mapping these by hand is fiddly and easy to get wrong.

Here is a small example of an entity using a PostgreSQL array and a JSONB column. Entity Developer can generate this shape from a table that already uses those types.

public partial class Product
{
    public Guid Id { get; set; }
    public string Name { get; set; } = "";
 
    // PostgreSQL text[] array column
    public string[] Tags { get; set; } = Array.Empty<string>();
 
    // PostgreSQL jsonb column, mapped to a C# object
    public ProductSpec Spec { get; set; } = new();
}
 
public class ProductSpec
{
    public string Color { get; set; } = "";
    public double WeightKg { get; set; }
}

Writing the right HasColumnType("jsonb") and array mappings by hand is the kind of detail people forget. The designer fills it in for you, so your model and your real PostgreSQL database agree.

A friendly comparison: by hand vs. with the tool

Let us be fair. You can do everything by hand. The question is how much time and how many mistakes.

Both reach the same finish line: a working EF Core model for PostgreSQL. The hand path has more steps where small errors hide. The tool path is shorter and more consistent, especially as the number of tables grows.

This does not mean you stop understanding EF Core. You still need to know what a DbContext is, what a relationship means, and how to write LINQ queries. Entity Developer removes the typing, not the thinking. A good teacher still wants you to understand the recipe even if a machine prints the card.

When is Entity Developer a good fit?

It is most helpful when:

• Your database has many tables and hand-writing classes is painful.
• Your team prefers seeing the model as a diagram.
• You work Database-First against an existing PostgreSQL schema.
• You want consistent generated code that follows one style.

It is less important when:

• Your app is tiny, with three or four tables you can type in minutes.
• Your whole team is happy and fast with pure Code-First migrations.

Also remember the editions. The free Express edition is limited to 10 entities and does not allow customizing the code templates. The paid Standard and Professional editions remove those limits. So for a serious, large project you would likely need a paid edition.

A quick note on the EF Core ecosystem

While we are here, a small accuracy note that helps you pick libraries wisely. Some popular .NET libraries you may have heard about, like MediatR and MassTransit, have moved to commercial licensing. They are still good tools, but they are no longer simply free for every use. Entity Developer is a separate, paid tool (with a free Express tier), so the same rule applies: check the license and edition before you commit a team to it.

For the database layer itself, EF Core stays free and open source, and the PostgreSQL provider Npgsql.EntityFrameworkCore.PostgreSQL is free too. Entity Developer is an optional productivity layer on top, not a replacement for EF Core.

Putting it together: a typical day

Here is how a developer might actually use the tool on a PostgreSQL project.

After regeneration, using the new property is plain EF Core. Nothing special.

// Ordinary EF Core query against the generated model
await using var db = new ShopDbContext(options);
 
var recentCustomers = await db.Customers
    .Where(c => c.Email.EndsWith("@gmail.com"))
    .OrderBy(c => c.Name)
    .Select(c => new { c.Name, c.Phone })  // Phone was just added
    .ToListAsync();

The point is that the generated code is normal EF Core code. There is no lock-in to a strange format. If you ever stop using Entity Developer, your C# classes keep working.

References and further reading

• Entity Developer — Visual ORM Design Tool (Devart)
• Entity Framework Core Designer (Devart)
• Model First approach (Devart)
• Database First approach (Devart)
• Getting Started With EF Core: Database-First and Model-First (Devart)
• Boost Your EF Core Productivity in PostgreSQL With Entity Developer (Anton Martyniuk)
• Npgsql EF Core provider for PostgreSQL

Quick recap

• EF Core has no built-in visual designer. Entity Developer adds one with a drag-and-drop diagram.
• It supports Database-First (import existing PostgreSQL tables) and Model-First (draw first, create tables later), and lets you mix them.
• Update From Database and Update To Database keep your model and PostgreSQL in sync in either direction.
• It uses T4 templates to generate consistent entity classes and your DbContext; paid editions let you customize the templates.
• It understands PostgreSQL features like UUID, JSONB, and arrays, so mappings are correct without manual fiddling.
• The free Express edition is capped at 10 entities with no template editing; bigger projects need a paid edition.
• The generated code is plain EF Core, so there is no lock-in — your classes work even without the tool.