Csharp-Razorpages

Razor Pages Code Style and Structure

- Write idiomatic, efficient Razor Pages and C#.

- Stick to the conventions the framework is built around: handler-based PageModels, not MVC controller patterns shoehorned into pages.

- Keep PageModels focused on request/response orchestration; business logic belongs in injected domain services.

- Trivial handlers can stay inline. For pages with lots of handlers and dependencies, reach for a mediator like MediatR.

- Use async/await end-to-end so handlers don't block the request pipeline.

Naming Conventions

- PascalCase for PageModel classes, handler methods, and public members (`CreateModel`, `OnPostAsync`, `OnPostDeleteAsync`).

- camelCase for private fields and locals, with the `_` prefix on private fields per the .NET convention (`_context`, `_logger`).

- Interface names start with "I" (`IEmailService`).

- Named handlers drop the `OnPost`/`Async` affixes when routed. `OnPostJoinListAsync` is reached as `handler=JoinList`.

Model Binding and Overposting

- Don't put `[BindProperty]` on EF or domain entities directly. An attacker can post extra fields like `IsAdmin` or `Secret` and the binder will happily set them, even if the form doesn't render them.

- Bind to a dedicated Input Model or View Model that exposes only the properties the page is allowed to accept, then map to the entity.

- `TryUpdateModelAsync<T>` with an explicit allow-list of properties is another option, especially in edit scenarios.

- Avoid `[Bind]` for edits. Excluded properties get reset to `default(T)` rather than left alone, which is rarely what you want. Prefer Input Models.

- Don't enable `[BindProperty(SupportsGet = true)]` broadly. Razor Pages skips GET binding by default for a reason; opt in per-property and validate what comes in.

- For custom types (including strongly-typed IDs), implement `TryParse` or a `TypeConverter` so they bind from route and query values. Without one, the binder treats them as complex types and binding silently fails. One of those bugs that wastes an afternoon.

- `[BindRequired]` and `[Required]` aren't the same thing. `[BindRequired]` errors when the source value is *absent* from the posted form; `[Required]` validates that the bound value isn't null/empty. `[BindRequired]` only applies to form binding, since JSON and XML go through input formatters instead.

Handler Methods and Request Flow

- Always use Post-Redirect-Get on successful POSTs. Return `RedirectToPage("./Index")`, never `Page()`. Returning `Page()` on success means a browser refresh resubmits the form.

public async Task<IActionResult> OnPostAsync()
{
    if (!ModelState.IsValid) return Page();          // re-render on error
    await _service.CreateAsync(Input);
    return RedirectToPage("./Index");                // PRG on success
}

- Guard every persistence path with `if (!ModelState.IsValid) return Page();`. Client-side validation can be bypassed; the server is authoritative.

- Use a handler parameter (`OnGetAsync(int id)`) for single-request route or query values. Use `[BindProperty]` for POST data that needs to round-trip back to the view on validation errors.

- Named handlers (`OnPostDeleteAsync`, `OnPostApproveAsync`) need the `asp-page-handler` tag helper on the submit button. Without it, plain buttons fall back to `OnPostAsync` or 404.

- If `OnGet` does expensive work, add a lightweight `OnHead`. Razor Pages falls back to `OnGet` for HEAD requests otherwise, so every probe pays the full GET cost.

- Filters work differently here than in MVC: `[ActionFilter]` attributes are silently ignored on page handlers. Use `IPageFilter` / `IAsyncPageFilter`, or register global conventions through `options.Conventions` in `Program.cs`.

Project Structure and Conventions

- Shared layouts, partials, and templates go in `Pages/Shared/`, not `Views/Shared/`. Razor Pages resolves views hierarchically from the page's folder up through `Pages/`, and mixing in MVC conventions just fights the framewo