NDjango.RestFramework — a C#/.NET port of DRF's conventions

[willianantunes-jsm]

Hi everyone,

Long-time DRF user here. I wanted to share a project that's been brewing for a while: NDjango.RestFramework — a port of DRF's conventions to C# / ASP.NET Core + EF Core.

It's not a rewrite of DRF, and it doesn't try to be a one-to-one clone. The goal is narrower: take the vocabulary and ergonomics DRF users already have in their heads — Serializer, perform_create / perform_update / perform_destroy, validate_<field> + validate(), partial=True, queryset-scoped writes, PageNumberPagination response shape — and make them feel native in idiomatic C# (generics instead of duck typing, IQueryable<T> instead of QuerySet, Task instead of sync views).

What that looks like in practice

A BaseController<TOrigin, TDestination, TPrimaryKey, TContext> gives you the standard CRUD surface in one declaration — list (with filters / search / sort / pagination), retrieve, create, update, partial update, delete, and an opt-in bulk delete. The PageNumberPagination response shape matches DRF's exactly (count / next / previous / results), and PATCH semantics are DRF-faithful via a PartialJsonObject<T> that tracks which fields were actually sent.

The seams DRF users reach for are all there:

• perform_create / perform_update / perform_destroy → PerformCreateAsync / PerformUpdateAsync / PerformDestroyAsync on the controller.
• validate_<field> → auto-discovered Validate{Field}Async hooks on the serializer, with a ValidationContext that exposes Operation / IsCreate / IsPartialUpdate / IsSet(field).
• validate() → an override ValidateAsync(...) cross-field hook that only runs if per-field hooks passed.
• get_object → a queryset-naive Serializer.GetObjectAsync(query, id, ct) that the controller composes onto its filter chain before every write, so a tenant/soft-delete filter protects PUT / PATCH / DELETE the same way it protects reads.

A deliberate divergence worth flagging: there's no HTTP bulk-update verb, mirroring DRF's stance that ListSerializer.update raises NotImplementedError because broadcasting one body to many rows is mass-assignment, not a generic update. Headless callers (consumers, jobs) can still call Serializer.UpdateManyAsync directly.

Learn by reading and running it

If you'd rather see this than read about it, the repo ships two things that exist precisely so newcomers don't have to take the README on faith:

• ./sample-project — a small ASP.NET Core service backed by SQL Server that uses the library the way a real consumer would. It models a tiny restaurant domain (Categories, Restaurants + nested RestaurantProfile, MenuItems, Ingredients, Tags, AuditLogs, TenantNotes, Gifts) and intentionally exercises one DRF idiom per resource:

  • Tags — per-field Validate{Name,Slug}Async hooks that normalize (trim / lowercase / dash-collapse) and do an async DB uniqueness check.
  • AuditLogs — ActionOptions gating, so PATCH / PUT / DELETE return 405 while still showing up in OpenAPI.
  • TenantNotes — a TenantNoteTenantFilter scoping by an X-Tenant header, demonstrating that the same filter chain protects writes (PUT / PATCH / DELETE / bulk-DELETE), not just reads — DRF's get_object behavior translated to EF Core IQueryable.
  • Restaurants — GetFields() nested-field projection ("RestaurantProfile:Website") for trimming serialized output without writing a custom serializer.
  • Gifts — a wide CLR-primitive surface (Guid, decimal, DateOnly, TimeOnly, TimeSpan, DateTimeOffset, …) to show the OpenAPI / serialization story for every common type.

• ./playwright — a Playwright end-to-end suite that drives the sample over real HTTP. The specs are organized by capability rather than by resource, so each file reads as executable documentation for a feature: crud.spec.ts, list-features.spec.ts (filter / search / sort / pagination), queryset-scope.spec.ts (out-of-scope ids → 404 on writes, silently dropped on bulk delete), tags.spec.ts (hook validation + normalization round-trip), audit-logs.spec.ts (405 gating), restaurants-nested.spec.ts, and openapi.spec.ts (contract assertions on the generated document).

docker compose up -d db && cd playwright && npm install && npm test — the test runner brings the sample up itself.

Why share it here

Mostly because the design has been guided by DRF's source at tag 3.17.1 — the mixins, the serializer pipeline, the pagination contract — and I'd rather the DRF community knows it exists than not. If anyone here has had to bounce between Django and .NET shops, hopefully this softens the landing.

The library is still pre-1.0 and explicitly not recommended for production yet (the README says so). Issues, ideas, and "this would have been more DRF-like if you'd done X" feedback are all very welcome.

[willianantunes-jsm]

One more thing worth mentioning for anyone who lands here from a Django/Python background: there's a sibling project in the same org that tackles the other half of the Django experience — the admin site.

NDjango.Admin is a Django-admin-inspired auto-generated admin dashboard for ASP.NET Core. Same spirit as the library above: take an idiom Django users already have in their heads and make it native in .NET. You register it with one line over your DbContext (or MongoDB collections), mount it at /admin, and you get the surface Django Admin users expect — dashboard home, list views with sorting / pagination / opt-in search, bulk actions (built-in "Delete selected" + custom AdminActionList<TPk>), create/edit forms with FK lookup popups that mirror raw_id_fields, M2M via junction entities, delete confirmation pages, and a sidebar with model navigation. Everything is server-rendered HTML — no client-side framework to wire up.

A few details that might matter to people coming from Django Admin specifically:

• Two storage providers out of the box: Entity Framework Core (full CRUD over your DbContext) and MongoDB (full CRUD over registered collections). The MongoDB provider auto-detects timestamp conventions (CreatedAt / UpdatedAt / CreatedDate / …) and treats them the same way Django Admin treats auto_now_add fields — hidden on create, read-only on edit, stamped by the manager.
• Auth modeled on Django Admin: cookie auth is always on, with users / groups / permissions tables (or collections) created automatically by a background hosted service. There's also optional SAML SSO.
• Per-collection / per-entity read-only mode, an IsReadOnly global switch, and EntityGroups to organize the sidebar — the kind of knobs ModelAdmin users will reach for first.
• Three sample projects in-repo (sample-project, sample-project-mongodb, sample-project-sso) plus a Playwright e2e suite, so you can spin it up and click through before adopting it.

Both libraries are pre-1.0 and the same "look at the tests / sample projects" caveat applies. Sharing it here in case anyone reading this thread is also missing the Django Admin side of the story in .NET — happy to hear feedback there too.

[Natgho]

With all due respect, I ask, “Why are you trying to reinvent the wheel?”

Speaking purely objectively, I ask, “When might a company or individual need this project?”

For a company that started out using Python, switching to C# is a major risk, and I can’t say I’ve ever seen a company make that decision before.

The DRF project has dozens of maintainers, yet it has faced issues with inactivity in recent years. Given that such problems can arise even with a project this popular, expecting someone from the group of people who “know C# but want to use Django, yet feel compelled to use .NET due to the requirement to use C#” to support this project (it’s great that you’ve started working on the project today, but who can guarantee you’ll still be willing to be a developer in the future?) seems a bit too optimistic to me.

When viewed from a C# perspective, this structure reveals a significant inconsistency. Generally, the C# community is (naturally) eager to follow what is known as the “Microsoft path.” This is somewhat akin to the paradox of saying, “I want to break my chains, but I like the chains.”

From a technical perspective, Python is a dynamic language (duck typing), while C# is a static and strict language. Trying to emulate Python’s flexibility in C# sometimes results in complex “generic” structures. If the library hits a roadblock at some point, you’ll need to know both DRF and decipher how the author adapted it to C# to resolve the issue.

If I found myself sitting across from this table one day and had to make a decision as an architect, I would either opt for using DRF with Python or decide to write in C# with ASP.NET. While your experimental work is commendable, it feels like the metaphor of a force a whale up a tree.

[willianantunes-jsm]

With 30+ critical C# apps in our portfolio, we aren't reinventing the wheel; we’re optimizing it. These libraries bridge the gap for teams needing better DX and faster delivery within the C# ecosystem.

[Natgho]

Actually, that’s exactly the crux of the matter: “It’s like trying to put a tire made for motorcycles on a truck.”
That’s why I’m asking:

1. “Do you think these tires will fit the truck?”
2. “Do you believe you’ll be able to supply these tires for the long term?”
3. “Why are you expending energy trying to create something from scratch instead of focusing on improving and making the most of the existing system?”

[willianantunes-jsm]

We have an even larger footprint in Python and Django. We know firsthand how much DRF and Django change the game.