EasyData: a CRUD API and admin UI generated from your DbContext

Metadata first, screens second

EasyData does not ask you to describe your entities twice. It takes the DbContext object you already have, reads the metadata from it, and derives two things from that metadata: an API endpoint for the CRUD operations, and the user interface pages and dialogs that talk to that endpoint. The practical consequence is the selling point of the project. When you add a DbSet or a new property to a model class, the interface adjusts itself, because the forms are not hand written against the shape of your data. The library is aimed at ASP.NET Core applications that use Entity Framework Core, and the documentation is explicit about where it fits: quick prototyping of a database related project, where you want a working web app with CRUD forms for your database in minutes rather than a week of controller and view code.

Three steps from an empty project to CRUD forms

Setup is deliberately short. First, two NuGet packages go into the project, `EasyData.AspNetCore` and `EasyData.EntityFrameworkCore.Relational`. Second, the middleware is added, and in the Program.cs style used by .NET 6 that is a single call that names the DbContext type used as the metadata source:

app.MapEasyData(options => {
    options.UseDbContext<AppDbContext>();
});

The older Startup.cs style does the same thing inside the endpoint mapping:

app.UseEndpoints(endpoints =>
{
    endpoints.MapEasyData(options => {
        options.UseDbContext<AppDbContext>();
    });

    endpoints.MapRazorPages();
});

Third, a catch-all page is added, which is covered in the next section. The type you pass to `UseDbContext` is the whole configuration surface at this level: it is what the API and the interface are generated from, so a second DbContext would need a second set of endpoints, and the documentation does not describe how two contexts are separated.

The catch-all page is where the interface is mounted

Every CRUD URL lives under a prefix that is `/easydata` by default and is configurable. A single page catches all of them, using a catch-all route parameter that swallows the rest of the path, and it loads the stylesheet, the script that renders the data management interface, and a dispatcher that starts it:

@{
    ViewData["Title"] = "EasyData";
}

<link rel="stylesheet" href="https://cdn.korzh.com/ed/1.4.8/easydata.min.css" />

<div id="EasyDataContainer"></div>

@section Scripts {
    <script src="https://cdn.korzh.com/ed/1.4.8/easydata.min.js" type="text/javascript"></script>
    <script>
        window.addEventListener('load', function () {
            new easydata.crud.EasyDataViewDispatcher().run()
        });
    </script>
}

Two details are worth noticing. The page is empty apart from a container div, because the interface is built in the browser from the metadata the API returns, so there is no server rendered markup to maintain. And the assets are loaded from the project CDN, pinned there to version 1.4.8, which is worth checking against the current package version before you rely on it in production.

Attributes are the configuration surface

Out of the box the tool works with every entity in the DbContext and every field in those tables, which is rarely what a production application wants. The escape hatch is a pair of annotations on your model classes and properties. `MetaEntity` with a false value hides a table:

[MetaEntity(false)]
public class Customer
{
 .   .   .   .
}

and `MetaEntityAttr` does the same for a single field, which is the usual way to keep a hash column out of an editable form:

public class User
{
    [MetaEntityAttr(false)]
    public string PasswordHash { get; set; }
}

The same attributes carry display metadata. `DisplayName`, `DisplayNamePlural` and `Description` rename a table in the interface, and on a property `Editable`, `ShowOnView` and `ShowInLookup` decide whether a field can be written, appears in the main data table, and is offered as a lookup. Since the annotations live on your model classes, the configuration ends up in the same place as the schema, which is convenient for prototypes and arguable for long lived domain models.

Filtering in the data view needs no code

One of the three headline features needs no configuration at all. In the data view mode, the interface provides data filtering that works out of the box and requires no extra setup or coding, which means a user can narrow a table to a subset without anyone writing a query. That capability comes from the same metadata driven design as the rest: the interface knows the type of every column, so it can offer filtering on the fields rather than only on the rows. The interesting question is what it does with the tables and fields you hid, and the documentation does not say, so the annotation test is the practical way to find out what an end user can still reach.

A lerna and nx monorepo behind two packages

The repository layout explains how a library like this is built. There is an `easydata.net/` directory for the server side, an `easydata.js/` directory for the browser side, a `playground/` directory, and a `samples/` directory that holds ready made applications for Angular, Blazor with a server, Blazor WebAssembly, MVC, Razor Pages on .NET 6, Razor Pages on .NET Core 3.1, and React on .NET 10. The build is a lerna and nx workspace, with scoped scripts for the core, crud and ui packages and a bundle-crud package, and the frontend is TypeScript bundled with rollup. The client side is published separately on npm as `@easydata/crud`, so a project that wants to drive the interface from its own front end can take the script rather than the generated pages.

The gap between a prototype and an admin tool

Everything documented here is about getting an interface on screen quickly, and nothing is documented about who is allowed to use it. The catch-all route exposes every entity in the DbContext, the API endpoint serves CRUD for all of them, and the project description does not mention authentication, authorisation, roles or an audit trail, so the obvious deployment mistake is to let anonymous requests reach the `/easydata` prefix. The documentation also does not explain what happens with validation rules, with concurrency, or with entity types that have no obvious form representation. On maintenance, the release line is active, with v1.6.0 published on 2026-09-19 after v1.5.10 in January 2026 and v1.5.8 in April 2025, and the last push was on 2026-09-19. The licence is MIT, and there is a separate developer document in the repository for working on the library itself.

Editorial conclusion

EasyData is a good fit for an internal tool, a demo, or an early prototype where an ASP.NET Core project needs working create, read, update and delete screens today, because two NuGet packages and a catch-all page are the entire setup. It is a poor fit for a production administration surface, since the project describes no access control model, no per-role permissions and no audit trail, and everything the DbContext exposes becomes reachable under the /easydata prefix. Before using it on anything real, hide the tables and fields you do not want with MetaEntity and MetaEntityAttr, confirm the /easydata prefix is not reachable by anonymous users, and check the version of easydata.min.js and easydata.min.css that you serve, because the documentation still points at the 1.4.8 assets on the project CDN while the latest release is 1.6.0.

Frequently asked questions

Official sources

1. Issues
2. KorzhCom/EasyData on GitHub
3. License: MIT
4. README
5. Releases