C# Dependency Injection: Transient, Scoped, Singleton Lifetimes Explained

💡 𝐆𝐥𝐨𝐛𝐚𝐥 𝐮𝐬𝐢𝐧𝐠𝐬 𝐢𝐧 𝐂# - 𝐬𝐭𝐨𝐩 𝐫𝐞𝐩𝐞𝐚𝐭𝐢𝐧𝐠 𝐭𝐡𝐞 𝐬𝐚𝐦𝐞 𝐮𝐬𝐢𝐧𝐠 𝐬𝐭𝐚𝐭𝐞𝐦𝐞𝐧𝐭𝐬 Most projects repeat the same 5-10 using statements across every file. It's boilerplate that adds noise without value. Global usings let you declare them once and use them everywhere. 🔹 What are global usings? Global usings are namespace imports you declare once in a single file, and they're available in every other file in your project. You use the global using keyword instead of the regular using keyword. The compiler treats them as if you'd written them at the top of every file. 🔹 How do you use them? Create a file called GlobalUsings.cs (or any name you prefer) and put your global using statements there. Common candidates: System, System.Collections.Generic, System.Linq, your company namespace, your most-used domain models. That's it - they're now available everywhere. 🔹 When does this matter? In larger projects with 50+ files, eliminating repetitive usings saves scrolling and makes the code cleaner. In small projects, the benefit is minimal. The real win is in maintaining shared libraries or conventions - one place to update, everywhere benefits. 🔹 The trap to avoid Don't make global usings a dumping ground. If you're only using a namespace in one or two files, keep the using local. Global usings work best for truly universal dependencies. Overuse makes it harder to understand what your code actually depends on. ✦ Declare global usings with global using Namespace; ✦ Keep them in a dedicated file like GlobalUsings.cs for discoverability ✦ Use global usings only for namespaces you need in most files ✦ Local using statements still override and add to global ones in the same file ♻️ Repost to help your team clean up using statements! 📌 Save this for later Subscribe to my weekly .NET newsletter 🚀 https://lnkd.in/drjE3rjP Follow Remigiusz Zalewski for more daily .NET tips 👇 #csharp #dotnet #aspnetcore #dotnetcore #codingtips #softwaredeveloper #programming #webdevelopment #careergrowth #developer #coding #aspnet

I hit a subtle bug this week that had nothing to do with data and everything to do with time ⏱️ I was using an imperative API that mutates a list based on index positions. The logic looked simple: move one item to index 0, another to index 1. Running them together produced inconsistent results ⚠️ The issue is that index based operations have positional side effects. Each mutation changes the structure, so the next operation no longer runs on the state you expected. The fix was not about data, but about execution order. Serializing the operations made the result deterministic. A good reminder: When you don’t control state declaratively, you have to control time imperatively 🧠 #javascript #webdevelopment #frontend #softwareengineering #async #programming #buildinpublic #webengineering --- I post about web engineering, front-end and soft skills in development. Follow me here: Irene Tomaini

🚀 .NET Insight: Mastering Dependency Injection (DI) 💡 What exactly is Dependency Injection? Dependency Injection is a way to design your code where: 👉 Classes don’t build the objects they need 👉 They receive those objects from an external source 📌 Think of it like this: “Your class focuses on what to do, not how to create dependencies.” ⚙️ Why does DI matter? ✔ Decoupled Code Changes in one service won’t break others ✔ Test-Friendly Easily plug in mocks or fake services ✔ Readable & Clean No clutter of new keyword everywhere ✔ Flexible Design Switch implementations without touching core logic ✔ Built for Growth Works best when your app starts scaling 🔁 Service Lifetimes in .NET ✔ Transient → Fresh instance every time it’s requested ✔ Scoped → Same instance within a single request ✔ Singleton → One shared instance across the app 🎯 Choosing the right lifetime: 👉 Transient → Small, stateless operations 👉 Scoped → DB-related work (like DbContext) 👉 Singleton → Global/shared utilities (logging, caching) ⚠️ Watch Out: Mixing lifetimes incorrectly (like Scoped inside Singleton) can lead to unexpected bugs. 💬 Final Thought Good developers write code that works. Great developers write code that is easy to change. Dependency Injection helps you become the second one. 📌 Save for quick revision 🚀 Follow for more practical .NET learnings #dotnet #csharp #dependencyinjection #backenddeveloper #softwareengineering #cleanarchitecture #codingtips #devcommunity #techtips #programming

🚨 If you don’t understand recursion… you’re not alone (but today that ends) Most developers hear the word recursion and immediately think: “Yeah… functions calling themselves… confusing stuff.” Let’s kill that confusion with one simple idea 👇 🧠 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗥𝗲𝗰𝘂𝗿𝘀𝗶𝗼𝗻 (𝗶𝗻 𝗽𝗹𝗮𝗶𝗻 𝗘𝗻𝗴𝗹𝗶𝘀𝗵)? Recursion is when a function solves a problem by: 1. Breaking it into smaller versions of the same problem 2. Calling itself to solve those smaller pieces 💡 𝗥𝗲𝗮𝗹-𝗹𝗶𝗳𝗲 𝗮𝗻𝗮𝗹𝗼𝗴𝘆 Think of opening Russian dolls 🪆 You open one → there’s another inside You open again → another inside This continues… Until you reach the smallest doll (no more inside) That smallest doll = Base Case Opening each doll = Recursive Call 💻 𝗦𝗶𝗺𝗽𝗹𝗲 𝗖𝗼𝗱𝗲 𝗘𝘅𝗮𝗺𝗽𝗹𝗲 (𝗙𝗮𝗰𝘁𝗼𝗿𝗶𝗮𝗹) 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯 𝘧𝘢𝘤𝘵𝘰𝘳𝘪𝘢𝘭(𝘯) { 𝘪𝘧 (𝘯 === 0) 𝘳𝘦𝘵𝘶𝘳𝘯 1; // 𝘉𝘢𝘴𝘦 𝘤𝘢𝘴𝘦 𝘳𝘦𝘵𝘶𝘳𝘯 𝘯 * 𝘧𝘢𝘤𝘵𝘰𝘳𝘪𝘢𝘭(𝘯 - 1); // 𝘙𝘦𝘤𝘶𝘳𝘴𝘪𝘷𝘦 𝘤𝘢𝘭𝘭 } 𝘧𝘢𝘤𝘵𝘰𝘳𝘪𝘢𝘭(5); // 5 * 4 * 3 * 2 * 1 = 120 ⚠️ 𝗚𝗼𝗹𝗱𝗲𝗻 𝗥𝘂𝗹𝗲𝘀 𝗼𝗳 𝗥𝗲𝗰𝘂𝗿𝘀𝗶𝗼𝗻 ✔ Always define a base case (to stop infinite calls) ✔ Each call should move closer to the base case ✔ Think in terms of smaller problems 🔥 𝗪𝗵𝗲𝗿𝗲 𝗥𝗲𝗰𝘂𝗿𝘀𝗶𝗼𝗻 𝗶𝘀 𝘂𝘀𝗲𝗱 𝗶𝗻 𝗿𝗲𝗮𝗹 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀 • Tree structures (DOM, file systems) • Graph traversal • Backtracking problems (like Sudoku) • APIs with nested data • UI components with nested children 💥 𝗣𝗿𝗼 𝗧𝗶𝗽 (𝗦𝗲𝗻𝗶𝗼𝗿 𝗺𝗶𝗻𝗱𝘀𝗲𝘁) If you can convert a problem into: “Solve it for N using solution of N-1” 👉 That’s a recursion problem. 👀 Challenge for you Can you write a recursive function for Fibonacci? Drop your answer below ⬇️ Let’s see who really understands it. #javascript #programming #webdevelopment #coding #developers #dsa #frontend #softwareengineering #DAY91

Derived state is one of the most subtle sources of bugs. Because it “looks correct”. Until it isn’t. Here’s the issue 👇 You store: → Original data → Derived data (filtered, sorted, computed) Now you have: ❌ Two sources of truth Over time: → They go out of sync → Bugs appear → Debugging becomes painful Example: → items → filteredItems If items update but filteredItems doesn’t… Your UI lies. What works: ✔ Derive data on render (not store it) ✔ Use memoization if expensive ✔ Keep single source of truth Key insight: If something can be derived… It shouldn’t be stored. That’s how you avoid state inconsistency bugs. #ReactJS #StateManagement #Frontend #SoftwareEngineering #JavaScript #AdvancedReact #Architecture #Engineering #Programming #CleanCode

Lately, while working with different developers, I noticed a small but interesting pattern. Most people are very comfortable with the common HTTP methods like GET, POST, PUT, PATCH, and DELETE. These are used almost every day, so it becomes second nature. But methods like HEAD and OPTIONS are often missed or not clearly understood. The thing is, they are not extra or optional. They are part of the core HTTP design. HEAD works like GET but returns only the headers, not the actual response body. It can be useful when you just want to check if a resource exists, or get metadata like file size or last modified time without downloading everything. OPTIONS is used to understand what operations are allowed on a resource. It also plays an important role in CORS, where the browser sends a preflight request before calling an API. Many times frameworks handle this automatically, so developers don’t even realize it’s happening. The reason these methods are often overlooked is simple. In real-world projects, we don’t directly use them as frequently, and most tutorials focus only on CRUD operations. But having a clear understanding of them strengthens your fundamentals. It gives a better picture of how the web actually works behind the scenes. Sometimes, it’s not about using everything daily, but about knowing what exists and why it exists. #WebDevelopment #BackendDevelopment #SoftwareEngineering #APIDevelopment #RESTAPI #HTTP #FullStackDeveloper #DeveloperLife #CodingTips #TechLearning #Programming #Developers #Coding #TechInsights #SoftwareDeveloper #LearningInPublic #DevCommunity #CodeNewbie #SystemDesign #WebArchitecture

Yesterday: You saw how login API works 🔐 Today: How apps show data instantly 📊 Example: GET /api/products You open a page… and data appears. Here’s what actually happens 👇 Frontend 💻 → requests product list API ⚙️ → receives request API → fetches data from database 🗄️ Database → returns data API → sends response Frontend → displays it 🎯 Most apps you use daily = this exact flow. Simple request → structured response → clean UI #DotNet #AspNetCore #WebAPI #FullStackDevelopment #BackendDevelopment #FrontendDevelopment #SoftwareDevelopment #Programming #Coding #DeveloperLife #TechLife #100DaysOfCode #LearnToCode #CodeNewbie #CodingJourney #TechExplained #LearnInPublic #SystemDesign #APIDevelopment #WebDevelopment #CareerGrowth #GrowthMindset

💡 𝐜𝐨𝐧𝐬𝐭 𝐯𝐬 𝐫𝐞𝐚𝐝𝐨𝐧𝐥𝐲 𝐢𝐧 𝐂# - 𝐭𝐡𝐞𝐲'𝐫𝐞 𝐧𝐨𝐭 𝐭𝐡𝐞 𝐬𝐚𝐦𝐞 𝐤𝐢𝐧𝐝 𝐨𝐟 𝐢𝐦𝐦𝐮𝐭𝐚𝐛𝐥𝐞 Most developers treat const and readonly as interchangeable "make it immutable" keywords. They're not. 🔹 What is const? const is a compile-time constant. The value is baked directly into the IL at every call site. It's fast, but it only works with primitives and strings. More importantly - if you change a const value in a shared library, every consumer assembly must be recompiled to pick up the new value. Without a rebuild, they silently keep the old one. 🔹 What is readonly? readonly is a runtime constant. The value is assigned once - at declaration or inside the constructor - and cannot be reassigned after that. It works with any type, not just primitives. Because the value is read at runtime, updating it in a library takes effect immediately after redeployment, no consumer rebuild needed. 🔹 The trap The most dangerous pattern is using const for values that feel stable but aren't guaranteed forever - default URLs, version strings, environment keys, timeout values. The second trap is assuming readonly means deep immutability. If your readonly field holds a List<T>, the reference is locked - but you can still call .Add(), .Remove(), or .Clear() freely. The field won't be reassigned, but the data inside changes without restriction. ✦ Use const only for true mathematical or logical constants - Pi, fixed multipliers, protocol version numbers ✦ Use readonly for anything resolved at runtime - configuration, injected values, computed results, library defaults ✦ readonly on a reference type locks the reference, not the object's internal state ♻️ Repost to spread the knowledge! 📌 Save this for later Subscribe to my weekly .NET newsletter 🚀 https://lnkd.in/drjE3rjP Follow Remigiusz Zalewski for more daily .NET tips 👇 #csharp #dotnet #aspnetcore #api #dotnetcore #codingtips #softwaredeveloper #programming #webdevelopment #careergrowth #developer #coding #aspnet

I used to see 𝐌𝐕𝐂 as just another pattern. 𝐌𝐨𝐝𝐞𝐥. 𝐕𝐢𝐞𝐰. 𝐂𝐨𝐧𝐭𝐫𝐨𝐥𝐥𝐞𝐫. It felt… 𝐭𝐡𝐞𝐨𝐫𝐞𝐭𝐢𝐜𝐚𝐥. Until I noticed something. Every time I opened an app… I was already interacting with 𝐌𝐕𝐂. When I click a button I don’t think about code. But internally… A system starts working. Here’s what actually happens: 𝐈 𝐜𝐥𝐢𝐜𝐤 → 𝐑𝐞𝐪𝐮𝐞𝐬𝐭 𝐠𝐨𝐞𝐬 𝐭𝐨 𝐂𝐨𝐧𝐭𝐫𝐨𝐥𝐥𝐞𝐫 Controller decides: “What needs to be done?” Then it talks to 𝐌𝐨𝐝𝐞𝐥 Model handles: → 𝐝𝐚𝐭𝐚 → 𝐥𝐨𝐠𝐢𝐜 → 𝐩𝐫𝐨𝐜𝐞𝐬𝐬𝐢𝐧𝐠 Once done… Controller sends it to 𝐕𝐢𝐞𝐰 And View shows the final result. And suddenly… It clicked. 𝐌𝐕𝐂 is not about code. It’s about 𝐜𝐥𝐚𝐫𝐢𝐭𝐲. Each part has a 𝐬𝐢𝐧𝐠𝐥𝐞 𝐫𝐨𝐥𝐞: 𝐌𝐨𝐝𝐞𝐥 → Thinks 𝐕𝐢𝐞𝐰 → Shows 𝐂𝐨𝐧𝐭𝐫𝐨𝐥𝐥𝐞𝐫 → Decides And that’s why frameworks like: 𝐒𝐩𝐫𝐢𝐧𝐠 𝐁𝐨𝐨𝐭 𝐀𝐒𝐏.𝐍𝐄𝐓 follow this structure. Because without this separation: Everything mixes. Logic + UI + Data → 𝐦𝐞𝐬𝐬. But with MVC: 𝐜𝐥𝐚𝐫 𝐟𝐥𝐨𝐰 𝐞𝐚𝐬𝐢𝐞𝐫 𝐝𝐞𝐛𝐮𝐠𝐠𝐢𝐧𝐠 𝐛𝐞𝐭𝐭𝐞𝐫 𝐬𝐜𝐚𝐥𝐚𝐛𝐢𝐥𝐢𝐭𝐲 Now whenever I build something… I don’t just think: “Will it work?” I think: “Is it 𝐨𝐫𝐠𝐚𝐧𝐢𝐳𝐞𝐝?” Because good systems don’t just run. They 𝐦𝐚𝐤𝐞 𝐬𝐞𝐧𝐬. What’s one concept that felt confusing… until you saw it in real life? #Java #SpringBoot #DotNet #ASPNet #MVC #Technology #Learning

I got tired of chasing frameworks. Every week there's a new framework. A new UI library. A new way to do the same thing. So I went the opposite direction. I built a native, concurrent file system analyzer in Go. No frameworks. No dependencies. No runtime required. Just a single <2.5MB executable that: • Scans thousands / millions of files in seconds • Uses ALL your CPU cores simultaneously • Finds duplicates, large files, recent files • Exports to CSV/JSON • Runs from a USB drive (no install) 50+ features. ~400+ lines of Go. Zero frameworks. This is my FIRST Go program. Not a todo app. Not a calculator. A production-ready, portable binary tool. Because real engineering isn't about the hottest framework. It's about building things that just work. Open source coming soon. download from here : https://lnkd.in/e3_4KyJZ What framework burnout are you recovering from? Let's discuss #golang #opensource #programming #cli #devtools