12 Battle-Tested Tips to Level Up as a Dotnet Developer
Writing code that just about works is easy. Writing code that handles production traffic without crashing, is secure, and easy to maintain for years is where the real skill of a dotnet developer shines.
Moving from building simple tutorials to managing complex enterprise applications means adopting new habits and rules. A great dotnet developer knows that clean structure and performance under load are just as important as the code itself.
To help you level up and avoid late-night debugging sessions, here are 12 practical, field-tested tips that separate junior programmers from senior engineers.
1. Master Dependency Injection Lifetimes
Dependency Injection (DI) is built right into the core of modern .NET, so there's no reason not to use it. But using it incorrectly can cause major issues, like memory leaks.
When you register a service in your DI container, you must choose the correct lifecycle:
-
Transient: A brand-new instance is created every single time you ask for it.
-
Scoped: One instance is created for the entire duration of an HTTP request.
-
Singleton: One single instance is created and used for the entire life of the application.
A very common mistake is injecting a Scoped service (like a database context) into a Singleton service. Because the Singleton never dies, it holds onto that database connection forever, which will eventually crash your application. Understanding how these lifecycles interact is not optional for a dotnet developer.
Here is an example of correct and incorrect registration:
C#
// --- Incorrect Registration ---
// This will create a new instance of IMyTransientService for every instance of IMySingletonService
public void ConfigureServices(IServiceCollection services)
{
// Violation: IMyTransientService should not be registered as Singleton if it holds disposable resources
services.AddSingleton<IMyTransientService, MyTransientService>();
// Violating Singleton with Scoped dependency:
services.AddSingleton<IMySingletonService, MySingletonService>();
// Where MySingletonService has a dependency on IMyScopedService
}
// --- Correct Registration ---
public void ConfigureServices(IServiceCollection services)
{
// Correct lifetimes:
services.AddTransient<IMyTransientService, MyTransientService>();
services.AddScoped<IMyScopedService, MyScopedService>();
// Correct Singleton registration:
services.AddSingleton<IMySingletonService, MySingletonService>();
// Where MySingletonService does NOT depend on a Scoped or Transient service
}
2. Never Block Asynchronous Code
Modern web development relies heavily on asynchronous programming to improve scalability. When you see .Result or .Wait() on an asynchronous method, it's a major red flag for any dotnet developer.
When you do this, you block the thread, potentially causing "thread pool starvation." This means your API will stop responding to new user requests because it has run out of available threads to process them. Always use async and await all the way up and down the call stack, from the controller level down to the database layer.
Here's an example of how to do it correctly and incorrectly:
C#
// --- Incorrect - Blocks the thread! ---
public async Task<IActionResult> MyEndpoint()
{
// The main thread waits (blocks) here until GetData() is complete,
// which can lead to starvation and poor performance under load.
var data = await _myService.GetData().Result;
return Ok(data);
}
// --- Correct - Uses fully async approach ---
public async Task<IActionResult> MyEndpoint()
{
// The main thread is released back to the thread pool to handle other requests
// while the async task completes in the background, making the app much more responsive.
var data = await _myService.GetData();
return Ok(data);
}
3. Entity Framework is Great, But Watch Your Queries
Entity Framework (EF) Core is a powerful tool, but if you're not careful, it can severely impact performance. Great dotnet developers always profile their queries to ensure they are optimized.
The biggest issue is the N+1 query problem. This happens when you load a list of items and then trigger a new database query for each item in the list to load related data. If you have 100 items, you just hit your database 101 times for a single page load. Always use .Include() to fetch related data in a single, clean query.
Also, use .AsNoTracking() for read-only queries where you don't intend to update the data. It tells EF Core not to waste memory tracking changes, providing a significant performance boost. And do not be afraid to drop EF Core entirely for high-performance read scenarios and write optimized raw SQL queries instead.
Here's how to fetch data efficiently with Entity Framework Core:
C#
// --- Incorrect - Potential N+1 query problem ---
public async Task<List<Order>> GetOrders(int customerId)
{
// Fetches all orders first, then for each order, it makes a *separate* query
// to fetch the OrderItems, causing N+1 queries for N orders.
var orders = await _context.Orders
.Where(o => o.CustomerId == customerId)
.ToListAsync();
foreach (var order in orders)
{
// This causes a database query to be executed *inside* the loop!
// Highly inefficient and a common performance killer.
var orderItems = await _context.OrderItems
.Where(oi => oi.OrderId == order.Id)
.ToListAsync();
// and add orderItems to the order object...
}
return orders;
}
// --- Correct - Eager loading prevents N+1 queries ---
public async Task<List<Order>> GetOrders(int customerId)
{
// Eagerly loads OrderItems for *all* fetched orders in a *single* efficient database query,
// preventing the N+1 problem and significantly improving performance.
var orders = await _context.Orders
.Where(o => o.CustomerId == customerId)
.Include(o => o.OrderItems) // Single query for both Orders and OrderItems
.ToListAsync();
return orders;
}
4. Cancellation Tokens are Not Optional
This is probably the most ignored feature in ASP.NET, but it is one of the most important for proper resource management.
Imagine a user clicks "Download Report" on your website, triggering a heavy, 10-second database query. After two seconds, the user gets impatient and closes the browser tab. Without a cancellation token, your server has no idea the user left, and it will keep wasting CPU and database resources for the full 10 seconds for absolutely no reason. By passing a CancellationToken through your methods, the framework will instantly kill the operation the moment the user disconnects, saving server capability and increasing efficiency.
Here is how to use a CancellationToken in your controllers and services:
C#
// --- Incorrect - Ignores cancellation ---
public async Task<IActionResult> MyEndpoint()
{
// This task will continue to run even if the user cancels the request,
// needlessly consuming resources on the server.
await _myService.DoLongRunningTask();
return Ok();
}
// --- Correct - Uses fully async approach with CancellationToken ---
public async Task<IActionResult> MyEndpoint(CancellationToken cancellationToken)
{
// This task is provided the cancellationToken and will stop processing
// immediately if the user cancels the request, preventing resource waste.
await _myService.DoLongRunningTask(cancellationToken);
return Ok();
}
5. Keep Your Controllers DUMB
Your API controllers should act like a traffic cop: receive the request, hand it off to a service to do the actual work, and then return the result. As a dotnet developer, you want to keep controllers minimal to improve testability and maintainability.
If you have 300 lines of business logic, tax calculations, and database calls stuffed directly inside a controller method, you are doing it wrong. That code becomes impossible to unit test. Move the heavy lifting into separate service classes. This keeps your code highly readable, testable, and much easier to maintain when you have to revisit it six months later.
Here’s an example of separating concerns with a controller and service:
C#
// --- Incorrect - Bloated controller method ---
public async Task<IActionResult> RegisterUser(UserRegistrationModel model)
{
// Validation, database interactions, email sending logic all inside the controller!
// Extremely hard to test and maintain this bloated method.
if (!ModelState.IsValid) return BadRequest(ModelState);
// ... complex validation ...
// ... database operations ...
// ... email sending ...
return Ok(newUser);
}
// --- Correct - Minimal controller, logic in service ---
// --- Inside the Controller ---
public async Task<IActionResult> RegisterUser(UserRegistrationModel model)
{
// Delegate the complex logic to the specific service method,
// keeping the controller focused and easy to test.
var newUser = await _userService.RegisterUser(model);
return Ok(newUser);
}
// --- Inside the Service ---
// Focuses solely on user registration logic, making it independently testable.
public async Task<User> RegisterUser(UserRegistrationModel model)
{
// Perform all validation, database, email logic here, separate from the controller,
// which enhances reusability and maintainability.
// ... validation ...
// ... database interactions ...
// ... email sending ...
return newUser;
}
6. Use Structured Logging, Not Text Files
Writing _logger.LogInformation("User logged in") feels helpful until you are staring at a massive text file with a million identical lines trying to find a specific bug.
Use structured logging libraries like Serilog. Instead of just printing text, structured logging saves your logs as easily searchable data objects. You can attach the user ID, the order number, and the exact timestamp. When things break, a skilled dotnet developer uses structured logs to filter through millions of entries in seconds instead of scrolling through Notepad for an hour.
Here's an example of how structured logging can save the day:
C#
// --- Incorrect - Traditional, unstructured logging ---
// Logs only basic string information, which is hard to filter and analyze effectively.
_logger.LogInformation("User with ID: " + user.Id + " updated profile.");
_logger.LogError("An error occurred: " + exception.Message);
// --- Correct - Structured logging (Serilog approach) ---
// Logs structured data that can be easily indexed, searched, and filtered
// in modern logging systems, significantly speeding up debugging.
_logger.LogInformation("User {UserId} updated profile.", user.Id);
_logger.LogError(exception, "An error occurred while updating profile for user {UserId}.", user.Id);
7. Centralize Your Exception Handling
Sprinkling try-catch blocks randomly throughout your entire codebase makes your files messy and guarantees you will handle errors inconsistently. Great dotnet developers always aim for centralized and consistent exception handling.
Instead, build a global exception handling middleware. Let your code throw errors naturally, and let the middleware catch them all in one central place. The middleware can log the exact error for your team and then return a clean, standard HTTP 500 error message to the user without exposing your sensitive database structure or stack trace.
Here's an example of how global exception handling works:
C#
// --- Incorrect - Sprinkled try-catch blocks ---
// Leads to repetitive, messy code and inconsistent error handling throughout the application.
public async Task<IActionResult> MyEndpoint()
{
try
{
await _myService.DoSomething();
}
catch (Exception ex)
{
// ... log the error ...
// ... return a generic error response ...
}
return Ok();
}
// --- Correct - Centralized Global Exception Handling ---
// A single middleware is responsible for catching *all* unhandled exceptions,
// ensuring consistency, improving logging, and simplifying individual methods.
public async Task<IActionResult> MyEndpoint()
{
// Simply call the service, knowing that the middleware will handle any exceptions gracefully.
await _myService.DoSomething();
return Ok();
}
// --- Exception Handling Middleware ---
public async Task Invoke(HttpContext context)
{
try
{
// Continues processing the rest of the application's pipeline.
await _next(context);
}
catch (Exception ex)
{
// Centralized location for all unhandled exceptions:
// log the details for debugging, then return a structured, clean error response to the user.
await HandleExceptionAsync(context, ex);
}
}
8. Drop EF Core for Heavy Read Operations
EF Core is fantastic for standard CRUD operations and updating data safely. But when you need to pull a massive amount of data for a complex reporting dashboard or analytics, EF Core carries a lot of overhead.
Don't be afraid to use a hybrid approach. Keep EF Core for your inserts and updates, but use a lightweight tool like Dapper to run raw, highly optimized SQL queries for your heaviest read operations. Any proficient dotnet developer uses the right tool for the specific job. Serving pre-joined, indexed data from memory takes a fraction of a millisecond, taking the load completely off your database and making your application feel incredibly fast.
Here's how to fetch data directly from a view for maximum performance:
C#
// --- Highly inefficient read-heavy query with EF Core ---
// This requires complex LINQ expressions, and potentially slow execution.
public async Task<List<ProductDetailViewModel>> GetProductDetails()
{
return await _context.Products
.Include(p => p.Category)
.Include(p => p.Supplier)
.Select(p => new ProductDetailViewModel { /* ... map all properties ... */ })
.ToListAsync();
}
// --- Highly optimized read-heavy query with direct SQL/View ---
// Bypasses Entity Framework overhead entirely, resulting in incredibly fast performance.
public async Task<List<ProductDetailViewModel>> GetProductDetailsDirectSql()
{
// Uses a pre-optimized database view to fetch pre-joined, ready-to-use data in a single, blazing-fast call.
return await _context.Set<ProductDetailViewModel>() // Provided the class matches the View's schema
.FromSqlRaw("SELECT * FROM dbo.vw_ProductDetails")
.ToListAsync();
}
9. Caching is Mandatory at Scale
If your homepage shows the exact same list of products to every single visitor, your server should not be asking the database for that list 500 times a minute. Database queries are expensive and slow, and minimizing them is a key optimization technique for a dotnet developer.
Implement caching. You can start with IMemoryCache for simple, single-server setups. If your application grows to run on multiple servers, switch to a distributed cache like Redis. Serving data from memory takes a fraction of a millisecond, taking the load completely off your database and making your site feel incredibly fast.
Here's an example of implementing a simple In-Memory cache:
C#
// --- Incorrect - Always queries the database ---
// Leads to heavy load on the database for frequently accessed, unchanging data.
public async Task<List<Product>> GetFeaturedProducts()
{
// Every request hits the database to fetch the exact same list of products.
return await _context.Products
.Where(p => p.IsFeatured)
.ToListAsync();
}
// --- Correct - Use IMemoryCache for frequently accessed data ---
// Prevents unnecessary database calls, improving response times and scalability.
public async Task<List<Product>> GetFeaturedProducts(CancellationToken cancellationToken)
{
// Use the optimized HybridCache API (for .NET 9+) for simplified, efficient caching.
return await _hybridCache.GetOrCreateAsync(
"featured_products_cache_key", // Unique key for this specific data
async cancel => await _context.Products.Where(p => p.IsFeatured).ToListAsync(cancel), // Logic to fetch fresh data if not in cache
cancellationToken: cancellationToken); // Respects request cancellation
}
10. Expect External APIs to Fail
If your application relies on a third-party payment gateway or an external weather API, it is guaranteed to fail eventually. Network connections randomly drop, and servers occasionally reboot. A good dotnet developer is prepared for this.
Instead of wrapping everything in a massive try-catch block and hoping for the best, look into resilience libraries like Polly. Polly allows you to set up automatic retry policies. If a payment gateway API times out, Polly can automatically wait two seconds and try again. If it fails three times, it can gracefully return a friendly error message to the user instead of throwing a massive, unreadable exception screen.
Here is an example of implementing a retry policy with Polly:
C#
// --- Incorrect - Will fail immediately if API is down ---
// Will crash the application or return an error response immediately if the external service is unavailable.
public async Task<PaymentResult> ProcessPayment(PaymentDetails details)
{
// Directly calls the unstable API without any safety mechanisms.
return await _paymentApi.Process(details);
}
// --- Correct - Uses Polly for resilience and retry policies ---
// Automatically handles temporary network issues or external API downtime, providing a seamless experience.
public async Task<PaymentResult> ProcessPayment(PaymentDetails details)
{
// Define a robust resilience pipeline using Polly to handle failures gracefully.
var pipeline = new ResiliencePipelineBuilder<PaymentResult>()
.AddRetry(new RetryStrategyOptions<PaymentResult> // Automatically retries upon failure
{
ShouldHandle = new PredicateBuilder<PaymentResult>().Handle<HttpRequestException>(), // Handles specific network exceptions
MaxRetryAttempts = 3, // Retries up to 3 times
Delay = TimeSpan.FromSeconds(2), // Waits 2 seconds between retries
BackoffType = DelayBackoffType.Exponential // Progressively increases the delay to be more resilient
})
.Build();
// Executes the unstable API call within the resilience pipeline.
return await pipeline.ExecuteAsync(async cancel => await _paymentApi.Process(details, cancel));
}
11. Move Heavy Work to Background Services
If a user uploading an image triggers a process that resizes the image, generates a thumbnail, and sends a confirmation email, do not make the user stare at a loading spinner while all of that happens. It provides a terrible user experience.
Return a "Success" message to the user immediately and pass the heavy processing tasks to a background worker like IHostedService or Hangfire. For an effective dotnet developer, offloading non-critical tasks to the background is crucial for maintaining an application's responsiveness. The user gets a fast response, and your server handles the heavy lifting in the background at its own pace.
Here is an example of implementing a simple background task:
C#
// --- Incorrect - Performs heavy work in the request thread ---
// Makes the user wait until the entire, time-consuming task is finished.
public async Task<IActionResult> ProcessFile(IFormFile file)
{
// Uploads the file, and *then* performs all resizing, processing in the request thread,
// which makes the user wait for a long time.
await _fileProcessor.ResizeAndCompressImage(file);
return Ok();
}
// --- Correct - Uses IHostedService for background processing ---
// Offloads heavy processing, providing a blazing-fast response to the user.
public async Task<IActionResult> ProcessFile(IFormFile file)
{
// Uploads the file, and immediately offloads the processing task to a separate background service.
// The main request thread is immediately released back to the pool to handle more user requests.
_fileQueue.Enqueue(file); // Adds the file to a queue for background processing
return Accepted(); // Returns an HTTP 202 'Accepted' response immediately
}
12. Deploy with Feature Flags
Deploying a massive new feature on a Friday afternoon is terrifying. Feature flags allow you to deploy new features to production while keeping them deactivated, which means any high-performing dotnet developer can release with more confidence and control.
By wrapping your new code in a feature toggle, you can turn it on just for your internal QA team to test in the live environment. If it causes bugs, you just flip the switch back to "off" without having to roll back your entire deployment, ensuring a reliable and safer release process.
Here is how simple a feature flag check can be:
C#
// --- Controller check for feature flag ---
// Determines whether to execute the new feature logic or the existing one based on the flag's value.
public async Task<IActionResult> GetNewDashboard()
{
// Seamlessly switches between existing and new dashboards using a central configuration.
if (await _featureManager.IsEnabledAsync("NewDashboard"))
{
return View("NewDashboard");
}
else
{
return View("ExistingDashboard");
}
}
The Standard of Professional Development
Software is about solving problems efficiently, not just writing clever syntax. By focusing on these core principles protecting your database, managing memory properly, and planning for failure you build applications that stand the test of time.
At Xovak Studio, our engineering team deals with these exact architectural decisions every single day. We apply strict coding standards to ensure that the platforms we build are fast, secure, and ready to scale effortlessly. Enforcing these standards is exactly how you keep performance high and maintenance headaches low for all high-level web projects.