---
title: "Building Scalable and Maintainable .NET Architectures: Real-World Best Practices"
subtitle: "Mastering .NET architecture for robust, scalable, and maintainable applications in real-world scenarios."
readTime: "25-30 minutes"
date: "2024-10-27"
language: "dotnet"
meta_description: "Learn real-world .NET architecture best practices for building scalable, maintainable applications. Explore design patterns, microservices, and performance optimization."
SEO_Keywords_List: "dotnet architecture, .NET architecture, real-world .NET, scalable .NET, maintainable .NET, .NET design patterns, microservices .NET, .NET performance, .NET best practices, clean architecture, domain-driven design, CQRS, event-driven architecture, .NET API, .NET web applications"
SEO_Meta_Description: "Master real-world .NET architecture. Build scalable, maintainable apps with best practices, design patterns, and microservices for optimal performance."
---
# Building Scalable and Maintainable .NET Architectures: Real-World Best Practices
## Introduction
Welcome to the world of .NET architecture! Building robust and scalable applications requires more than just writing code. Understanding and applying architectural principles is crucial for creating maintainable, testable, and high-performing systems. This guide will walk you through real-world .NET architecture best practices, patterns, and strategies to help you build better applications. We will cover everything from foundational concepts to advanced techniques, ensuring you have a solid understanding regardless of your experience level.
## Estimated Read Time: 25-30 Minutes
## Blog Outline
1. **Understanding the Fundamentals:**
* 1.1 What is .NET Architecture?
* 1.2 Why is Good Architecture Important?
* 1.3 Key Architectural Principles (SOLID, DRY, KISS, YAGNI)
2. **Layered Architecture:**
* 2.1 Presentation Layer (UI)
* 2.2 Application Layer (Business Logic)
* 2.3 Domain Layer (Core Business Rules)
* 2.4 Infrastructure Layer (Data Access, External Services)
* 2.5 Example Implementation with ASP.NET Core
3. **Domain-Driven Design (DDD):**
* 3.1 Ubiquitous Language
* 3.2 Entities and Value Objects
* 3.3 Aggregates and Repositories
* 3.4 Domain Services
* 3.5 Example: Implementing a simple DDD model
4. **Design Patterns in .NET:**
* 4.1 Dependency Injection (DI)
* 4.2 Repository Pattern
* 4.3 Unit of Work Pattern
* 4.4 Factory Pattern
* 4.5 Observer Pattern
* 4.6 Implementing DI with ASP.NET Core's built-in container
5. **Microservices Architecture with .NET:**
* 5.1 What are Microservices?
* 5.2 Benefits and Drawbacks
* 5.3 Communication Patterns (REST, gRPC, Message Queues)
* 5.4 Implementing a Simple Microservice with ASP.NET Core Web API
* 5.5 Containerization with Docker
6. **Event-Driven Architecture:**
* 6.1 Understanding Event-Driven Architecture
* 6.2 Message Queues (RabbitMQ, Kafka)
* 6.3 Implementing Event Producers and Consumers
* 6.4 Example: Using RabbitMQ with .NET
7. **CQRS (Command Query Responsibility Segregation):**
* 7.1 Understanding CQRS Principles
* 7.2 Separating Read and Write Models
* 7.3 Implementing a Simple CQRS Pattern
* 7.4 MediatR Library for CQRS implementation
8. **API Design Best Practices:**
* 8.1 RESTful API Principles
* 8.2 Versioning Strategies
* 8.3 Authentication and Authorization
* 8.4 API Documentation (Swagger/OpenAPI)
* 8.5 Example: Designing a RESTful API with ASP.NET Core
9. **Security Considerations:**
* 9.1 Common Vulnerabilities (OWASP Top 10)
* 9.2 Authentication and Authorization Techniques (OAuth 2.0, JWT)
* 9.3 Data Protection and Encryption
* 9.4 Input Validation and Sanitization
10. **Performance Optimization:**
* 10.1 Caching Strategies (Memory Cache, Distributed Cache)
* 10.2 Asynchronous Programming
* 10.3 Database Optimization (Indexing, Query Optimization)
* 10.4 Code Profiling with .NET Profiler/PerfView
* 10.5 Choosing the right data structures
11. **Common Pitfalls:**
* 11.1 Over-Engineering
* 11.2 Tight Coupling
* 11.3 Ignoring Security Concerns
* 11.4 Neglecting Testing
12. **Conclusion:**
* 12.1 Summary of Key Concepts
* 12.2 Practical Recommendations
* 12.3 Further Learning Resources
## In-Depth Blog Content
### 1. Understanding the Fundamentals
#### 1.1 What is .NET Architecture?
.NET architecture refers to the structural design of a .NET application. It defines the components, their relationships, and how they interact to achieve specific goals. It's about making informed decisions on how to organize your code, manage dependencies, and ensure that your application is easy to maintain, extend, and test.
#### 1.2 Why is Good Architecture Important?
Good architecture provides numerous benefits:
* **Maintainability:** Easier to understand and modify the codebase.
* **Scalability:** Ability to handle increasing workloads without significant performance degradation.
* **Testability:** Code can be easily tested, ensuring quality and reducing bugs.
* **Reusability:** Components can be reused in different parts of the application or in other applications.
* **Reduced Complexity:** Breaks down the application into manageable parts.
#### 1.3 Key Architectural Principles
* **SOLID:** A set of five design principles aimed at making software more understandable, flexible, and maintainable.
* **Single Responsibility Principle (SRP):** A class should have only one reason to change.
* **Open/Closed Principle (OCP):** Software entities should be open for extension, but closed for modification.
* **Liskov Substitution Principle (LSP):** Subtypes must be substitutable for their base types.
* **Interface Segregation Principle (ISP):** Clients should not be forced to depend on methods they do not use.
* **Dependency Inversion Principle (DIP):** High-level modules should not depend on low-level modules. Both should depend on abstractions.
* **DRY (Don't Repeat Yourself):** Avoid duplicating code by extracting common logic into reusable components.
* **KISS (Keep It Simple, Stupid):** Favor simplicity over complexity.
* **YAGNI (You Ain't Gonna Need It):** Don't implement features that you don't currently need.
### 2. Layered Architecture
Layered architecture is a widely used architectural pattern that organizes an application into distinct layers. Each layer has a specific responsibility, and communication between layers typically occurs in a top-down manner.
#### 2.1 Presentation Layer (UI)
The presentation layer is responsible for handling user interaction and displaying data. This could be a web application (ASP.NET Core MVC or Razor Pages), a mobile app (Xamarin or MAUI), or a desktop application (WPF).
#### 2.2 Application Layer (Business Logic)
The application layer orchestrates the business logic. It receives requests from the presentation layer, validates them, and coordinates the execution of domain logic. It doesn't contain business rules itself.
#### 2.3 Domain Layer (Core Business Rules)
The domain layer contains the core business rules and logic of the application. It's independent of any particular technology or framework. This layer typically contains entities, value objects, and domain services.
#### 2.4 Infrastructure Layer (Data Access, External Services)
The infrastructure layer provides support for data access, external service integration, and other technical concerns. It handles the details of interacting with databases, message queues, and external APIs.
#### 2.5 Example Implementation with ASP.NET Core
```csharp
// Domain Layer (Entities)
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
}
// Infrastructure Layer (Repository)
public interface IProductRepository
{
Product GetById(int id);
void Add(Product product);
}
public class ProductRepository : IProductRepository
{
private readonly AppDbContext _context;
public ProductRepository(AppDbContext context)
{
_context = context;
}
public Product GetById(int id)
{
return _context.Products.Find(id);
}
public void Add(Product product)
{
_context.Products.Add(product);
_context.SaveChanges();
}
}
// Application Layer (Service)
public interface IProductService
{
Product GetProduct(int id);
void CreateProduct(string name, decimal price);
}
public class ProductService : IProductService
{
private readonly IProductRepository _productRepository;
public ProductService(IProductRepository productRepository)
{
_productRepository = productRepository;
}
public Product GetProduct(int id)
{
return _productRepository.GetById(id);
}
public void CreateProduct(string name, decimal price)
{
var product = new Product { Name = name, Price = price };
_productRepository.Add(product);
}
}
// Presentation Layer (Controller) - ASP.NET Core
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
private readonly IProductService _productService;
public ProductsController(IProductService productService)
{
_productService = productService;
}
[HttpGet("{id}")]
public IActionResult Get(int id)
{
var product = _productService.GetProduct(id);
if (product == null)
{
return NotFound();
}
return Ok(product);
}
[HttpPost]
public IActionResult Post(string name, decimal price)
{
_productService.CreateProduct(name, price);
return Ok();
}
}
3. Domain-Driven Design (DDD)
Domain-Driven Design (DDD) is an approach to software development that centers the development process on the domain, or the specific subject area, for which the application is being built. It emphasizes a deep understanding of the domain and uses that knowledge to create a software model that closely reflects the real-world concepts.
3.1 Ubiquitous Language
The Ubiquitous Language is a common language used by developers, domain experts, and other stakeholders to communicate about the domain. This language should be used in the code, documentation, and communication.
3.2 Entities and Value Objects
- Entities: Objects with a unique identity that persists over time. (e.g.,
Customer,Order). - Value Objects: Objects that are defined by their attributes and do not have a unique identity. (e.g.,
Address,Money).
3.3 Aggregates and Repositories
- Aggregates: Clusters of associated objects that are treated as a single unit. An aggregate has a root entity which is the entry point for interacting with the aggregate. This simplifies data consistency and transactions..
- Repositories: Provide an abstraction over the data access layer, allowing you to interact with data sources without directly coupling to the underlying technology.
3.4 Domain Services
Domain services contain business logic that does not naturally belong to an entity or value object.
3.5 Example: Implementing a simple DDD model
// Value Object
public class Address
{
public string Street { get; private set; }
public string City { get; private set; }
public string ZipCode { get; private set; }
public Address(string street, string city, string zipCode)
{
if (string.IsNullOrWhiteSpace(street) || string.IsNullOrWhiteSpace(city) || string.IsNullOrWhiteSpace(zipCode))
{
throw new ArgumentException("Address components cannot be empty.");
}
Street = street;
City = city;
ZipCode = zipCode;
}
// Value object logic (equality comparison)
public override bool Equals(object obj)
{
if (obj == null || GetType() != obj.GetType())
{
return false;
}
Address other = (Address)obj;
return Street == other.Street && City == other.City && ZipCode == other.ZipCode;
}
public override int GetHashCode()
{
return HashCode.Combine(Street, City, ZipCode);
}
}
// Entity
public class Customer
{
public Guid Id { get; private set; }
public string Name { get; private set; }
// Address is a value object
public Address ShippingAddress { get; private set; }
public Customer(string name, Address shippingAddress)
{
Id = Guid.NewGuid();
Name = name ?? throw new ArgumentNullException(nameof(name));
ShippingAddress = shippingAddress ?? throw new ArgumentNullException(nameof(shippingAddress));
}
// Domain Logic: Simulate changing the address
public void UpdateShippingAddress(Address newAddress)
{
ShippingAddress = newAddress ?? throw new ArgumentNullException(nameof(newAddress));
}
}
// Aggregate Root (an Order, containing OrderItems)
public class Order
{
public Guid Id { get; private set; }
public Customer Customer { get; private set; }
private readonly List<OrderItem> _orderItems = new List<OrderItem>();
public IReadOnlyCollection<OrderItem> OrderItems => _orderItems.AsReadOnly();
public DateTime OrderDate {get; private set;}
public Order (Customer customer)
{
Id = Guid.NewGuid();
Customer = customer ?? throw new ArgumentNullException(nameof(customer));
OrderDate = DateTime.UtcNow;
}
public void AddOrderItem(OrderItem item)
{
if (item == null) throw new ArgumentNullException(nameof(item));
_orderItems.Add(item);
}
}
public class OrderItem {
public Guid Id { get; private set; }
public string ProductName {get; private set;}
public decimal Price { get; private set; }
public int Quantity {get; private set;}
public OrderItem(string productName, decimal price, int quantity)
{
Id = Guid.NewGuid();
ProductName = productName ?? throw new ArgumentNullException(nameof(productName));
Price = price;
Quantity = quantity;
}
}
// Repository Interface
public interface ICustomerRepository
{
Customer GetById(Guid id);
void Add(Customer customer);
}
// Repository Implementation
public class CustomerRepository : ICustomerRepository
{
private readonly AppDbContext _context; // Replace with your actual DbContext
public CustomerRepository(AppDbContext context)
{
_context = context;
}
public Customer GetById(Guid id)
{
return _context.Customers.Find(id);
}
public void Add(Customer customer)
{
_context.Customers.Add(customer);
_context.SaveChanges();
}
}
4. Design Patterns in .NET
Design patterns are reusable solutions to commonly occurring problems in software design. They provide a proven template for solving specific design challenges.
4.1 Dependency Injection (DI)
Dependency Injection is a design pattern that allows you to decouple components by providing dependencies to a class rather than creating them within the class.
4.2 Repository Pattern
The repository pattern provides an abstraction over the data access layer, making it easier to test and swap out data access technologies.
4.3 Unit of Work Pattern
The Unit of Work pattern tracks all changes made to the database during a business transaction. It commits all changes at once at the end of the transaction, ensuring data consistency.
4.4 Factory Pattern
The factory pattern provides an interface for creating objects without specifying the exact class to be created.
4.5 Observer Pattern
The observer pattern defines a one-to-many dependency between objects, so that when one object changes state, all its dependents are notified and updated automatically.
4.6 Implementing DI with ASP.NET Core's built-in container
// Interface
public interface IEmailService
{
void SendEmail(string to, string subject, string body);
}
// Implementation
public class EmailService : IEmailService
{
public void SendEmail(string to, string subject, string body)
{
// Implementation to send email
Console.WriteLine($"Sending email to: {to}, Subject: {subject}, Body: {body}");
}
}
// Controller
public class MyController : ControllerBase
{
private readonly IEmailService _emailService;
// Inject the IEmailService dependency through the constructor
public MyController(IEmailService emailService)
{
_emailService = emailService;
}
[HttpGet("send")]
public IActionResult Send()
{
_emailService.SendEmail("test@example.com", "Hello", "This is a test email.");
return Ok();
}
}
// Startup.cs (ConfigureServices method)
public void ConfigureServices(IServiceCollection services)
{
// Register the IEmailService interface with the EmailService implementation
services.AddScoped<IEmailService, EmailService>();
services.AddControllers();
}
5. Microservices Architecture with .NET
5.1 What are Microservices?
Microservices are a style of software development where an application is structured as a collection of small, autonomous services, modeled around a business domain. Each service can be deployed, scaled, and updated independently.
5.2 Benefits and Drawbacks
Benefits:
- Independent Deployment: Services can be deployed and updated independently, enabling faster release cycles.
- Scalability: Individual services can be scaled independently based on their specific needs.
- Technology Diversity: Different services can use different technologies, allowing you to choose the best tool for the job.
- Fault Isolation: A failure in one service does not necessarily bring down the entire application.
Drawbacks:
- Increased Complexity: Managing a distributed system can be more complex than managing a monolithic application.
- Distributed Transactions: Maintaining data consistency across multiple services can be challenging.
- Monitoring and Logging: Monitoring and logging events across multiple services requires a robust infrastructure.
5.3 Communication Patterns
- REST (Representational State Transfer): A widely used architectural style for building web services. Services communicate via HTTP requests and responses.
- gRPC (gRPC Remote Procedure Calls): A high-performance RPC framework developed by Google. Uses Protocol Buffers for data serialization.
- Message Queues (RabbitMQ, Kafka): Enable asynchronous communication between services. One service publishes messages to a queue, and other services consume those messages.
5.4 Implementing a Simple Microservice with ASP.NET Core Web API
// ProductService.cs
// Model
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
}
// Controller
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
private static List<Product> _products = new List<Product>()
{
new Product { Id = 1, Name = "Laptop", Price = 1200.00M },
new Product { Id = 2, Name = "Mouse", Price = 25.00M }
};
[HttpGet]
public IActionResult Get()
{
return Ok(_products);
}
[HttpGet("{id}")]
public IActionResult Get(int id)
{
var product = _products.FirstOrDefault(p => p.Id == id);
if (product == null)
{
return NotFound();
}
return Ok(product);
}
}
// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new OpenApiInfo { Title = "ProductService", Version = "v1" });
});
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
app.UseSwagger();
app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json", "ProductService v1"));
}
app.UseRouting();
app.UseAuthorization();
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}
5.5 Containerization with Docker
# Dockerfile
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["ProductService.csproj", "./"]
RUN dotnet restore "./ProductService.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "ProductService.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "ProductService.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "ProductService.dll"]
6. Event-Driven Architecture
6.1 Understanding Event-Driven Architecture
Event-Driven Architecture (EDA) is a software architecture pattern promoting the production, detection, and consumption of events. An event signifies a state change or occurrence within a system.
6.2 Message Queues (RabbitMQ, Kafka)
- RabbitMQ: A widely used message broker that supports multiple messaging protocols.
- Kafka: A distributed streaming platform that provides high throughput and fault tolerance.
6.3 Implementing Event Producers and Consumers
6.4 Example: Using RabbitMQ with .NET
// Producer
using RabbitMQ.Client;
using System.Text;
public class EventProducer
{
public static void Publish(string message)
{
var factory = new ConnectionFactory { HostName = "localhost" }; // Replace with your RabbitMQ server address
using (var connection = factory.CreateConnection())
using (var channel = connection.CreateModel())
{
channel.QueueDeclare(queue: "myqueue", durable: false, exclusive: false, autoDelete: false, arguments: null);
var body = Encoding.UTF8.GetBytes(message);
channel.BasicPublish(exchange: "", routingKey: "myqueue", basicProperties: null, body: body);
Console.WriteLine($" [x] Sent {message}");
}
}
}
// Consumer
using RabbitMQ.Client;
using RabbitMQ.Client.Events;
using System.Text;
public class EventConsumer
{
public static void Consume()
{
var factory = new ConnectionFactory { HostName = "localhost" }; // Replace with your RabbitMQ server address
using (var connection = factory.CreateConnection())
using (var channel = connection.CreateModel())
{
channel.QueueDeclare(queue: "myqueue", durable: false, exclusive: false, autoDelete: false, arguments: null);
var consumer = new EventingBasicConsumer(channel);
consumer.Received += (model, ea) =>
{
var body = ea.Body.ToArray();
var message = Encoding.UTF8.GetString(body);
Console.WriteLine($" [x] Received {message}");
};
channel.BasicConsume(queue: "myqueue", autoAck: true, consumer: consumer);
Console.WriteLine(" Press [enter] to exit.");
Console.ReadLine();
}
}
}
7. CQRS (Command Query Responsibility Segregation)
7.1 Understanding CQRS Principles
CQRS (Command Query Responsibility Segregation) is an architectural pattern that separates read and write operations for a data store.
7.2 Separating Read and Write Models
With CQRS, you have separate models for handling commands (write operations) and queries (read operations). This allows you to optimize each model for its specific purpose.
7.3 Implementing a Simple CQRS Pattern
7.4 MediatR Library for CQRS Implementation
MediatR is a simple, unambitious mediator implementation in .NET. It allows you to decouple your application logic by routing requests to handlers. It's commonly used for implementing CQRS.
// Install MediatR package: Install-Package MediatR
// Command
public record CreateProductCommand(string Name, decimal Price) : IRequest<int>;
// Command Handler
public class CreateProductCommandHandler : IRequestHandler<CreateProductCommand, int>
{
private readonly AppDbContext _context;
public CreateProductCommandHandler(AppDbContext context)
{
_context = context;
}
public async Task<int> Handle(CreateProductCommand request, CancellationToken cancellationToken)
{
var product = new Product { Name = request.Name, Price = request.Price };
_context.Products.Add(product);
await _context.SaveChangesAsync(cancellationToken);
return product.Id;
}
}
// Query
public record GetProductQuery(int Id) : IRequest<Product>;
// Query Handler
public class GetProductQueryHandler : IRequestHandler<GetProductQuery, Product>
{
private readonly AppDbContext _context;
public GetProductQueryHandler(AppDbContext context)
{
_context = context;
}
public async Task<Product> Handle(GetProductQuery request, CancellationToken cancellationToken)
{
return await _context.Products.FindAsync(request.Id);
}
}
// Controller
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
private readonly IMediator _mediator;
public ProductsController(IMediator mediator)
{
_mediator = mediator;
}
[HttpPost]
public async Task<IActionResult> CreateProduct(string name, decimal price)
{
var command = new CreateProductCommand(name, price);
var productId = await _mediator.Send(command);
return Ok(productId);
}
[HttpGet("{id}")]
public async Task<IActionResult> GetProduct(int id)
{
var query = new GetProductQuery(id);
var product = await _mediator.Send(query);
if (product == null)
{
return NotFound();
}
return Ok(product);
}
}
// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
services.AddMediatR(typeof(Startup)); // Register MediatR. 'typeof(Startup)' tells MediatR to scan current assembly
services.AddScoped<AppDbContext>(); // replace with your actual DbContext creation
services.AddControllers();
}
8. API Design Best Practices
8.1 RESTful API Principles
- Stateless: Each request from the client to the server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server.
- Client-Server: The client and server should be independent and can evolve separately.
- Cacheable: Responses should be cacheable to improve performance.
- Uniform Interface: Use standard HTTP methods (GET, POST, PUT, DELETE) and follow consistent naming conventions.
- Layered System: Allows for intermediary servers (proxies, load balancers) to improve scalability and security.
8.2 Versioning Strategies
Versioning allows you to introduce new features or make breaking changes to your API without affecting existing clients.
- URI Versioning: Include the version number in the URI (e.g.,
/api/v1/products). - Header Versioning: Use a custom header to specify the version (e.g.,
X-API-Version: 1). - Media Type Versioning: Specify the version in the
Acceptheader (e.g.,Accept: application/vnd.mycompany.product-v1+json).
8.3 Authentication and Authorization
- Authentication: Verifying the identity of the user.
- Authorization: Determining what resources the user is allowed to access. Common strategies:
- OAuth 2.0: A delegated authorization framework that allows users to grant third-party applications limited access to their resources.
- JWT (JSON Web Token): A compact, self-contained way to securely transmit information between parties as a JSON object.
8.4 API Documentation (Swagger/OpenAPI)
Swagger (now known as OpenAPI) is a specification for documenting APIs. It provides a standardized way to describe the endpoints, parameters, and responses of an API. Tools like Swashbuckle.AspNetCore can automatically generate Swagger documentation for your ASP.NET Core APIs.
8.5 Example: Designing a RESTful API with ASP.NET Core
// Controller
[ApiController]
[Route("api/v{version:apiVersion}/products")]
[ApiVersion("1.0")]
public class ProductsController : ControllerBase
{
private static List<Product> _products = new List<Product>()
{
new Product { Id = 1, Name = "Laptop", Price = 1200.00M },
new Product { Id = 2, Name = "Mouse", Price = 25.00M }
};
[HttpGet]
public IActionResult Get()
{
return Ok(_products);
}
[HttpGet("{id}")]
public IActionResult Get(int id)
{
var product = _products.FirstOrDefault(p => p.Id == id);
if (product == null)
{
return NotFound();
}
return Ok(product);
}
[HttpPost]
[Authorize] // Requires authentication.
public IActionResult Post(string name, decimal price)
{
// Implementation to create a new product (requires authorization).
// Example: Only users with "Admin" role can create products.
return CreatedAtAction(nameof(Get), new {id=3}, new Product { Id = 3, Name = "Keyboard", Price = 75.00M });
}
}
// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();
// API Versioning
services.AddApiVersioning(o => {
o.ReportApiVersions = true;
o.AssumeDefaultVersionWhenUnspecified = true;
o.DefaultApiVersion = new ApiVersion(1, 0);
});
services.AddSwaggerGen(c =>
{
c.SwaggerDoc("v1", new OpenApiInfo { Title = "Products API", Version = "v1" });
// Configure authentication with Swagger (e.g., JWT Bearer scheme)
c.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme {
Description = "JWT Authorization header using the Bearer scheme.",
Name = "Authorization",
In = ParameterLocation.Header,
Type = SecuritySchemeType.Http,
Scheme = "bearer"
});
c.AddSecurityRequirement(new OpenApiSecurityRequirement
{
{
new OpenApiSecurityScheme
{
Reference = new OpenApiReference
{
Type = ReferenceType.SecurityScheme,
Id = "Bearer"
}
},
new string[] {}
}
});
});
// Add authentication services (e.g., JWT). Simplified version; adjust based on real needs.
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options => {
options.Authority = "YOUR_AUTH_SERVER_URL"; // Replace with your actual Auth server
options.Audience = "YOUR_API_AUDIENCE"; // Configure audience if needed.
});
services.AddAuthorization();
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
if (env.IsDevelopment())
{
app.UseDeveloperExceptionPage();
app.UseSwagger();
app.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json", "Products API v1"));
}
app.UseHttpsRedirection();
app.UseRouting();
app.UseAuthentication(); // Enable authentication
app.UseAuthorization(); // Enable authorization
app.UseEndpoints(endpoints =>
{
endpoints.MapControllers();
});
}
9. Security Considerations
9.1 Common Vulnerabilities (OWASP Top 10)
The OWASP Top 10 is a list of the ten most critical security risks to web applications. Understanding and mitigating these vulnerabilities is crucial for building secure .NET applications. some of the common vulnerabilities include:
- Injection: SQL injection, command injection, etc.
- Broken Authentication: Weak passwords, insecure session management.
- Cross-Site Scripting (XSS): Attacker injects malicious scripts into web pages.
- Insecure Direct Object References: Exposing internal object references to unauthorized users.
- Security Misconfiguration: Default configurations, unnecessary features enabled.
- Cross-Site Request Forgery (CSRF): Attacker tricks a user into performing unwanted actions on a website they are authenticated on.
- Using Components with Known Vulnerabilities: Using outdated libraries or frameworks with known security flaws.
- Insufficient Logging & Monitoring: Lack of proper logging and monitoring makes it difficult to detect and respond to security incidents.
- Server-Side Request Forgery (SSRF) Attacker can make requests to internal resources
- Improper Inventory Management Lack of tracking of APIs and applications that can lead to security blindspots.
9.2 Authentication and Authorization Techniques
- OAuth 2.0: A delegated authorization framework commonly used for granting third-party applications limited access to user resources.
- JWT (JSON Web Token): A compact, self-contained way to securely transmit information between parties as a JSON object.
9.3 Data Protection and Encryption
- Data Encryption at Rest: Protect sensitive data stored in databases or files using encryption algorithms (e.g., AES).
- Data Encryption in Transit: Use HTTPS (TLS/SSL) to encrypt data transmitted over the network.
9.4 Input Validation and Sanitization
- Input Validation: Verify that user input conforms to expected data types, formats, and ranges.
- Input Sanitization: Remove or encode potentially malicious characters from user input.
10. Performance Optimization
10.1 Caching Strategies
- Memory Cache:
Enjoyed this article?
Explore more deep dives into architecture, performance, and modern .NET.