Best Practices in Architecture and .NET Development

“Best practice” is one of the most abused terms in software engineering. It usually means “what looks defensible in a slide deck” rather than “what actually works in production”. The articles in this collection treat the label with skepticism — every practice is a trade-off, and the only honest question is which trade-off applies to the situation in front of you.

The framing across these articles is consistent: a practice is worth adopting when the failure mode it prevents matters more than the overhead it adds. SOLID principles are a starting point, not a creed. Clean Code passages get quoted in code reviews far more often than the code in the repository reflects them. The articles examine where the gap between stated practice and actual behavior comes from and what changes that gap in real teams.

Specific topics span the .NET stack and the systems built on top of it. Defensive programming with throw helpers, multi-targeting build hygiene, central package management, structured logging that does not lie about what happened, mutation testing that exposes the blind spots line coverage hides, and TimeProvider adoption two years after it shipped — each is treated as a concrete intervention with measurable cost and benefit rather than a virtue to be signaled.

A separate cluster addresses the practices that hold up under pressure: incident response procedures rehearsed before the incident, audit logging that survives the audit, access control that fails closed, and feedback loops that catch regressions before customers do. The recurring observation is that practices fail not because they are wrong but because they are applied as rituals rather than as decisions with named consequences.

The collection also documents the practices the author has changed his mind about. Calling a pattern a best practice today and a mistake five years later is normal — the discipline is naming why the context shifted, not pretending the original advice was always correct.

Source Generators: The Build Performance Killer

Source Generator Costs

Source generators are powerful. They are also running on every single build, blocking IntelliSense, breaking Hot Reload, and multiplying their cost across every target framework you support. Nobody mentions this in the getting started guides. Here is how to measure the damage, find the culprits, and decide when source generators are actually worth it.

Green Dashboard, Dead Application

Your application just crashed in production. Azure App Service kept routing traffic to the failing instance for ninety seconds. Users saw timeouts. Your monitoring dashboard stayed green because the web server responded with HTTP 200 while the database connection pool was exhausted.

I’ve watched this exact scenario play out at three different organizations in the past year. Each time, the post-mortem revealed the same root cause: health checks that verified the process was breathing without checking whether it could actually do its job. ISO/IEC 27001 Control A.17.2.1 exists precisely for this reason—availability is a security control, not an operational afterthought.

Your Logout Button Is Lying: ASP.NET Session Security Done Right

That StackOverflow answer suggesting Session.Timeout = Int32.MaxValue for “better UX”? It’s how security becomes checkbox theater. Sessions that never expire, logout buttons that don’t invalidate tokens, cookies transmitted over HTTP—auditors catch these patterns immediately. Here’s how to configure ASP.NET Core authentication that actually works.

Your Incident Response Plan Is a Lie. Here's How to Fix It.

That incident response plan in your Confluence? Nobody reads it. The on-call engineer can’t find it. And when your production API is bleeding at 3 AM, you’ll improvise—badly. ISO 27001 A.16 doesn’t care about your documentation theater. It demands procedures that work. GitHub Actions turns incident response from compliance fiction into executable reality.

Stop Hoarding Personal Data in Entity Framework

The classic monolithic User entity—stuffed with birth dates, phone numbers, employment history, and marital status “just in case”—turns into a compliance nightmare the moment someone requests data deletion. You can’t delete without breaking referential integrity. You can’t keep the data without violating GDPR. You can’t anonymize without retaining fields that should never have existed. The solution isn’t complex: separate operational data from personal data, make consent-based fields nullable and purpose-documented, implement soft deletes with query filters, and validate your API boundaries with integration tests that fail when unnecessary fields leak through. Data minimization isn’t regulatory overhead—it’s architectural hygiene that makes your deletion logic straightforward and your audit responses honest.