|
Hey Reader, Ever tried to choose the perfect weapon for each creature in a dark, spooky forest? Silver bullets for werewolves, garlic for vampires, chainsaws for zombies... but what if you had to pick your weapon before entering the forest? Just like that forest adventure, dependency injection in C# can leave you stuck with the wrong tool when you need it most - unless you know about the Factory Pattern! Today, I’m breaking down how the Factory Pattern solves real-world dependency injection issues and when to use it instead of conventional DI. If you’re interested in dynamically switching dependencies at runtime (instead of being locked in beforehand), this is for you! Watch on YouTube 📺Check out the full tutorial to see how the Factory Pattern saves the day 👇 The Problem: Static Dependencies in DIIn typical dependency injection, you declare services upfront, which locks in certain dependencies at compile time. Let’s say we’re working with different services to handle weapons:
Registered in the builder.Services.AddScoped But here’s the catch: this setup only lets you pick one weapon before runtime. That’s fine if you’re only fighting vampires, but if you encounter a zombie with garlic in hand… well, you’re out of luck! The Factory Pattern SolutionEnter the Factory Pattern! With this approach, we can dynamically choose the right weapon at runtime based on the creature we’re facing. Here’s how it’s done: Step 1: Define a Factory Interface
Step 2: Implement the Factory
Step 3: Register Services and Factory in
|
Become a .NET & Blazor expert with weekly tutorials featuring best practices and the latest improvements, right in your inbox.
Hey friend, I just released a new video and wanted to share it with you. Watch the video here 👇 I used GitHub Copilot to build a small Blazor weather app. It worked almost instantly and even used real API calls. At first glance, everything looked great. Then I opened the Razor file. All the logic was sitting in one place. UI, API calls, and business logic mixed together. It worked, but it was not something I would ship. In the video, I show how I fix this using a single refactoring prompt. I...
Hey friend, I just released a new video and I think you will enjoy this one. In the video, I ask GitHub Copilot to build a real mortgage app in Blazor. The app works. But the code is messy. All the business logic ends up in the UI. Fast results. Bad structure. Then I clean it up properly. Same behavior. Same output. Much better code using services, interfaces, and dependency injection. It shows why Copilot is powerful, but dangerous without rules. Watch the video here 👇 Enjoy the breakdown...
Hey friend, I just released a new video and I think you’ll enjoy it. In the video, I ask GitHub Copilot to build a .NET Web API using a short, vague prompt. The result works, but the structure feels random and messy. Then I run the same idea again with a stronger prompt that forces a clean structure. Feature folders. Vertical slice. Mediator. Fluent Validation. The difference is night and day. Watch the video here 👇 Enjoy the breakdown and let me know what you think. Take care, Patrick P.S....