Posts

Why Repository Abstractions Usually Hurt Blazor Apps More Than Help “You didn’t decouple EF Core. You just hid it badly.”

-
Image
 “You didn’t decouple EF Core. You just hid it badly.” I’ve built this architecture. More than once. Early in my Blazor projects, adding repository abstractions felt like the responsible thing to do. The code looked clean. The layers were clear. Code reviews were easy. Then the app grew. The team changed. Performance started to matter. That’s when the repository layer stopped helping—and started getting in the way. This article isn’t about theory. It’s about what I’ve learned the hard way, maintaining long-lived Blazor applications. Why I Used Repositories (And Why They Felt Right) I didn’t introduce repositories because I was careless. I did it because: Books recommended them Talks showcased them Juniors expected them “Clean Architecture” diagrams normalized them And early on? They worked. That’s the trap. The Year-Two Problem The pain never shows up in month three. It shows up when: Queries need tunin...
Post a Comment
Read more

Stop Hardcoding AppSettings: A Clean Pattern for Blazor Environment Configuration

-
Image
  If your Blazor app works locally but breaks in Azure, there’s a good chance configuration is the real bug. Blazor developers often treat configuration as a startup concern —something you wire up once and forget. That works… until you add environments. or feature flags. or secrets. or a second app. Then the configuration quietly turns into a distributed liability . Let’s talk about why hardcoded AppSettings patterns don’t scale—and a cleaner, environment-aware approach that actually survives real projects. The Common (But Fragile) Pattern Most Blazor apps start like this: // appsettings.json {   "InCounter": 5,   "FeatureFlagStyleTable": true } Var styleTable = configService.Value.FeatureFlagStyleTable; At first, this feels fine. Then you add: appsettings.Development.json appsettings.Test.json appsettings.Production.json Azure App Service settings Feature flags Secrets in Key Vault Suddenly: ...
Post a Comment
Read more

Stop Asking for Real-Time Data (You Probably Don’t Need It) Or: Why “real time” is one of the most expensive words in software architecture.

-
Image
  The uncomfortable truth After decades of building enterprise systems, here’s an observation that makes some people uncomfortable: Most people who ask for “real-time” data updates don’t actually need real time. What they want is confidence , responsiveness , and trust — not millisecond precision. And yet, the moment the phrase real time enters a requirements meeting, costs go up, architectures get complicated, and teams quietly inherit a system they now have to babysit forever. What people say vs. what they actually mean When someone says: “We need this data in real time.” They usually mean: “I don’t want stale data.” “I don’t want to refresh the page.” “I want to react quickly.” “I want to trust what I’m seeing.” None of those requires true real-time infrastructure. They require fast-enough data and good UX . Once you cross into true real time , you introduce: Persistent connections Stateful servers Fan-out scaling challenges Reconnection logic O...
Post a Comment
Read more

Does Anyone Know What Time It Is?

-
Image
  If you’ve ever written a unit test that failed only on Tuesdays , only after midnight , or only on CI but never locally , then congratulations — you’ve been personally victimized by DateTime.Now . Time is one of those sneaky dependencies we rarely think about… until it breaks our tests. Thankfully, modern C# finally gives us a first-class way to deal with time in a testable, civilized way: 👉 TimeProvider Let’s talk about why it exists, why it matters, and how it makes your unit tests calmer, cleaner, and way less haunted. 🧨 The Classic Problem: Time Is a Liar Here’s a pattern we’ve all written: public bool IsExpired ( DateTime expiresOn ) { return DateTime.Now > expiresOn; } Seems harmless, right? Now try to unit test it. What time is it right now ? What happens if the test runs at midnight? What about daylight saving time? What if the test is slow? What if it runs in a different time zone? You don’t control time — time controls you . 🧠 Enter: TimePr...
Post a Comment
Read more

Modernize Your Code, Modernize Your Thinking

-
Image
  Why “One Class per File” Is Outdated—and What Modern C# Developers Should Do Instead For decades, C# developers have lived by a simple rule: “One class or interface per file.” This rule was so common that many of us (myself included) never questioned it. It became part of our coding DNA—just like putting braces on their own line (hello, 2005) or creating separate IService and Service folders. But today, we’re writing code in C# 12 , designing systems with Vertical Slice Architecture , navigating code with AI-powered tools , and building applications that emphasize features , not ceremony . Yet this ancient rule still lingers. Let’s be honest: ✔ It made sense years ago. ✘ It makes far less sense today. If you want to modernize your codebase , you must begin by modernizing your mindset . Let’s dive in. 🏛️ The Legacy of “One Class per File” This rule grew out of a different era—an era when: ✔ IDEs were primitive Early Visual Studio couldn’t n...
Post a Comment
Read more