Regira Entities is a CRUD and REST library for .NET, built on Entity Framework Core. Your EF Core model stays in control — Regira Entities adds the infrastructure around it. Implement one interface and the repetitive 80% of every backend — create, read, update, search, paging, attachments — collapses into configuration. It's convention-based: sensible defaults handle the common case, so you only write code for what actually needs customizing.
Free without a key, up to five simple and two complex entity types. License when a project grows past that. Attachments store their files through the Regira IO storage abstraction.
Implement IEntity<TKey> — that's the only requirement. Timestamps, soft-delete, normalized search and attachments are opt-in marker interfaces.
A separated read/write pipeline: query builders, filters, processors, preppers and primers — each a DI-registered seam you extend à la carte.
A basic CRUD entity is a one-line registration and a one-line controller — your POCO is the only model you write. Search, paging and sorting come standard; add code only where you need to.
Defaults we'd want in our own apps: search objects bind only the properties they declare, so over-posting can't reach the entity; reads run untracked; every call is async with cancellation; nullable reference types throughout.
Five moving parts across a separated read and write pipeline. Use as much or as little as you need — each lives behind its own interface.
builder.Services
.UseRegira(LICENSE) // free tier and trial available
.UseEntities<MyDbContext>(options => options.UseDefaults())
.For<Category>()
.For<Product, int, ProductSearchObject>(item => {
// inline configuration
item.SortBy((query, _) => query.OrderBy(x => x.Title));
item.Includes((query, _) => query.Include(x => x.Category));
item.Filter((query, so) =>
{
if (so?.CategoryId?.Any() == true)
query = query.Where(x => so.CategoryId.Contains(x.CategoryId));
return query;
});
})
.For<Order, int, OrderSearchObject, OrderSortBy, OrderIncludes>(item => {
// external classes for configuration
item.AddSortBy<OrderSortedBuilder>();
item.AddIncludes<OrderIncludableBuilder>();
item.AddFilter<OrderQueryFilter>();
// OrderRepository will handle OrderItems
item.Related(c => c.OrderItems);
});List, details, count, exists — paged and sorted by the search object, with post-fetch processors for any extra shaping. Reads run untracked.
Tracked add, modify and remove. Preppers shape data before save; primers run inside the SaveChanges interceptor for audit and normalization.
When a search property needs more than equality, drop in a filter class. The repository discovers and applies it.
Entity services come with a built-in wrapper so you can layer behaviour onto every method without touching the implementation. Add logging, caching, validation, tenancy or audit trails in one place — the underlying service stays clean, and consumers keep calling the same interface.
Every moving part above is a registered service behind its own interface. Compose the repository, opt in to filters, hooks, mappers, validators and includes via fluent extensions on IServiceCollection. SOLID by construction, swappable per project, easy to test.
Three ideas do almost all the work. Full, always-current code samples live in the package docs and API reference.
| ① Entity | Plain EF Core POCOs. No base class is required to get the basics; opt into change-tracking, audit and soft-delete interfaces when you want them. |
|---|---|
| ② Search object | A DTO that lists what's searchable. Each property becomes part of the predicate; paging, sorting and includes come along for the ride. |
| ③ Repository | A queryable surface — read, write, count, paginate, hydrate related data — wired through DI behind an interface, so swap and test as you like. |
Declare what's searchable in a plain DTO; each property the caller sets becomes part of the predicate. The same shape works from a query string, an HTTP body, or an LLM tool call.
| Search object | POCO with optional properties. Each property becomes an AND condition. |
|---|---|
| Paging & sort | PageSizePageSortBy |
| Includes | Eager-load related collections via a declared Includes property, without writing .Include() per call. |
| From HTTP | Bind from [FromQuery] directly — works as a GET filter or a POST body. |
| From an LLM | The DTO becomes the tool schema. Models can hit the repository with a payload like {"q":"acme","isActive":true}. |
Because conditions are declared in plain C# types, exposing the repository to an LLM is a small adapter, not a rewrite. The model gets a typed surface; you keep the safety of EF.
| Tool schema | The search-object DTO maps 1-to-1 onto a function signature the model can call. |
|---|---|
| Payload | The model emits JSON shaped like the DTO — {"q":"acme","isActive":true,"pageSize":20} — and your code passes it straight to the repository. |
| Safety | EF Core stays in the loop, so tenant filters, validation and access rules apply regardless of who's calling. |
Packages are published on nuget.org — free tier included, no sign-up. Need bigger limits? Licensing takes a minute.
JSON-in, image-out. Generate barcodes, compose PDFs, render labels — same approach, different output.