MVC, Minimal APIs, and Filters

"When would you use X over Y" questions aren't asking for a verdict — they're asking whether you make decisions with criteria. The failing answer picks a side with vibes ("minimal APIs are more modern"). The passing answer names the axes and lets the context decide.

MVC vs Minimal APIs

"New service — controllers or minimal APIs?" Clarify first: what kind of service? Then the criteria: Minimal APIs shine for small, endpoint-shaped services — less ceremony, route handlers as lambdas, great for microservices and internal APIs. MVC controllers earn their weight when you have views to render, large route surfaces that benefit from controller grouping, heavy use of filters, and — decisive for a Kendo-grid, server-rendered line-of-business app — the whole view/model-binding/validation apparatus. For a statewide transcript-review MVC application, the honest answer is controllers, said without apology: "the stack is MVC, the team knows MVC, and the feature set uses what MVC adds. I'd use minimal APIs for small internal endpoints beside it." Knowing minimal APIs gained filter support and typed results in recent releases signals currency; claiming MVC is "legacy" signals the opposite.

Filters vs middleware — the placement question

"You need to log every request, and separately audit who viewed each transcript. Where does each go?" The criterion is what context you need. Request logging needs only HTTP context → middleware, early in the pipeline. The audit needs to know which action, which transcript ID, which authenticated reviewer → an MVC filter, because filters run inside MVC with model-bound context that middleware never sees.

Have the filter ladder ready at one line each: authorization filters (first, short-circuit unauthenticated), resource filters (around binding — caching), action filters (around the action — your audit log), exception filters (MVC-scoped error shaping), result filters (around result execution). Follow-up they like: "global exception middleware or an exception filter?" Middleware catches everything including non-MVC failures; filters can produce MVC-aware responses like a ProblemDetails with model context. Many real apps have both, and saying so beats picking one.

Model binding and validation edge cases

The set-up question: "Your action takes UpdateReviewDto dto and someone POSTs malformed JSON — what runs?" Points to hit: binding happens before the action; a body that can't deserialize leaves ModelState invalid — and in a plain MVC controller the action still executes unless you check ModelState.IsValid (the [ApiController] attribute is what auto-returns 400). Candidates who think validation "just happens" walk into this. Second edge: over-posting — binding a request straight to an EF entity lets an attacker set fields you never rendered (IsApproved=true). The fix is the DTO/ViewModel boundary, which you should present as a security habit, not a style choice.

Practice prompts:

1. Answer "controllers or minimal APIs for our next service?" with a clarifying question first, then criteria.
2. Place these correctly and justify: tenant resolution, response compression, per-action audit logging, converting DbUpdateConcurrencyException to a 409.
3. Explain over-posting and its fix as you would to a security reviewer.