mirror of https://github.com/abpframework/abp.git
maliming
9 months ago
1228 changed files with 45572 additions and 7662 deletions
@ -0,0 +1,89 @@ |
|||
# ABP.IO Platform 10.0 Final Has Been Released! |
|||
|
|||
We are glad to announce that [ABP](https://abp.io/) 10.0 stable version has been released today. |
|||
|
|||
## What's New With Version 10.0? |
|||
|
|||
All the new features were explained in detail in the [10.0 RC Announcement Post](https://abp.io/community/announcements/announcing-abp-10-0-release-candidate-86lrnyox), so there is no need to review them again. You can check it out for more details. |
|||
|
|||
## Getting Started with 10.0 |
|||
|
|||
### How to Upgrade an Existing Solution |
|||
|
|||
You can upgrade your existing solutions with either ABP Studio or ABP CLI. In the following sections, both approaches are explained: |
|||
|
|||
### Upgrading via ABP Studio |
|||
|
|||
If you are already using the ABP Studio, you can upgrade it to the latest version. ABP Studio periodically checks for updates in the background, and when a new version of ABP Studio is available, you will be notified through a modal. Then, you can update it by confirming the opened modal. See [the documentation](https://abp.io/docs/latest/studio/installation#upgrading) for more info. |
|||
|
|||
After upgrading the ABP Studio, then you can open your solution in the application, and simply click the **Upgrade ABP Packages** action button to instantly upgrade your solution: |
|||
|
|||
 |
|||
|
|||
### Upgrading via ABP CLI |
|||
|
|||
Alternatively, you can upgrade your existing solution via ABP CLI. First, you need to install the ABP CLI or upgrade it to the latest version. |
|||
|
|||
If you haven't installed it yet, you can run the following command: |
|||
|
|||
```bash |
|||
dotnet tool install -g Volo.Abp.Studio.Cli |
|||
``` |
|||
|
|||
Or to update the existing CLI, you can run the following command: |
|||
|
|||
```bash |
|||
dotnet tool update -g Volo.Abp.Studio.Cli |
|||
``` |
|||
|
|||
After installing/updating the ABP CLI, you can use the [`update` command](https://abp.io/docs/latest/CLI#update) to update all the ABP related NuGet and NPM packages in your solution as follows: |
|||
|
|||
```bash |
|||
abp update |
|||
``` |
|||
|
|||
You can run this command in the root folder of your solution to update all ABP related packages. |
|||
|
|||
## Migration Guides |
|||
|
|||
There are a few breaking changes in this version that may affect your application. Please read the migration guide carefully, if you are upgrading from v9.x: [ABP Version 10.0 Migration Guide](https://abp.io/docs/10.0/release-info/migration-guides/abp-10-0) |
|||
|
|||
## Community News |
|||
|
|||
### New ABP Community Articles |
|||
|
|||
As always, exciting articles have been contributed by the ABP community. I will highlight some of them here: |
|||
|
|||
* [Alper Ebiçoğlu](https://abp.io/community/members/alper) |
|||
* [Optimize your .NET app for production Part 1](https://abp.io/community/articles/optimize-your-dotnet-app-for-production-for-any-.net-app-wa24j28e) |
|||
* [Optimize your .NET app for production Part 2](https://abp.io/community/articles/optimize-your-dotnet-app-for-production-for-any-.net-app-2-78xgncpi) |
|||
* [Return Code vs Exceptions: Which One is Better?](https://abp.io/community/articles/return-code-vs-exceptions-which-one-is-better-1rwcu9yi) |
|||
* [Sumeyye Kurtulus](https://abp.io/community/members/sumeyye.kurtulus) |
|||
* [Building Scalable Angular Apps with Reusable UI Components](https://abp.io/community/articles/building-scalable-angular-apps-with-reusable-ui-components-b9npiff3) |
|||
* [Angular Library Linking Made Easy: Paths, Workspaces and Symlinks](https://abp.io/community/articles/angular-library-linking-made-easy-paths-workspaces-and-5z2ate6e) |
|||
* [erdem çaygör](https://abp.io/community/members/erdem.caygor) |
|||
* [Building Dynamic Forms in Angular for Enterprise](https://abp.io/community/articles/building-dynamic-forms-in-angular-for-enterprise-6r3ewpxt) |
|||
* [From Server to Browser: Angular TransferState Explained](https://abp.io/community/articles/from-server-to-browser-angular-transferstate-explained-m99zf8oh) |
|||
* [Mansur Besleney](https://abp.io/community/members/mansur.besleney) |
|||
* [Top 10 Exception Handling Mistakes in .NET](https://abp.io/community/articles/top-10-exception-handling-mistakes-in-net-jhm8wzvg) |
|||
* [Berkan Şaşmaz](https://abp.io/community/members/berkansasmaz) |
|||
* [How to Dynamically Set the Connection String in EF Core](https://abp.io/community/articles/how-to-dynamically-set-the-connection-string-in-ef-core-30k87fpj) |
|||
* [Oğuzhan Ağır](https://abp.io/community/members/oguzhan.agir) |
|||
* [The ASP.NET Core Dependency Injection System](https://abp.io/community/articles/the-asp.net-core-dependency-injection-system-3vbsdhq8) |
|||
* [Selman Koç](https://abp.io/community/members/selmankoc) |
|||
* [5 Things Keep in Mind When Deploying Clustered Environment](https://abp.io/community/articles/5-things-keep-in-mind-when-deploying-clustered-environment-i9byusnv) |
|||
* [Muhammet Ali ÖZKAYA](https://abp.io/community/members/m.aliozkaya) |
|||
* [Repository Pattern in ASP.NET Core](https://abp.io/community/articles/repository-pattern-in-asp.net-core-2dudlg3j) |
|||
* [Armağan Ünlü](https://abp.io/community/members/armagan) |
|||
* [UI/UX Trends That Will Shape 2026](https://abp.io/community/articles/UI-UX-Trends-That-Will-Shape-2026-bx4c2kow) |
|||
* [Salih](https://abp.io/community/members/salih) |
|||
* [What is That Domain Service in DDD for .NET Developers?](https://abp.io/community/articles/what-is-that-domain-service-in-ddd-for-.net-developers-uqnpwjja) |
|||
* [Building an API Key Management System with ABP Framework](https://abp.io/community/articles/building-an-api-key-management-system-with-abp-framework-28gn4efw) |
|||
* [Fahri Gedik](https://abp.io/community/members/fahrigedik) |
|||
* [Signal-Based Forms in Angular](https://abp.io/community/articles/signal-based-forms-in-angular-21-9qentsqs) |
|||
|
|||
Thanks to the ABP Community for all the content they have published. You can also [post your ABP related (text or video) content](https://abp.io/community/posts/create) to the ABP Community. |
|||
|
|||
## About the Next Version |
|||
|
|||
The next feature version will be 10.1. You can follow the [release planning here](https://github.com/abpframework/abp/milestones). Please [submit an issue](https://github.com/abpframework/abp/issues/new) if you have any problems with this version. |
|||
|
After Width: | Height: | Size: 127 KiB |
|
After Width: | Height: | Size: 16 KiB |
@ -0,0 +1,277 @@ |
|||
# Repository Pattern in the ASP.NET Core |
|||
|
|||
If you’ve built a .NET app with a database, you’ve likely used Entity Framework, Dapper, or ADO.NET. They’re useful tools; still, when they live inside your business logic or controllers, the code can become harder to keep tidy and to test. |
|||
|
|||
That’s where the **Repository Pattern** comes in. |
|||
|
|||
At its core, the Repository Pattern acts as a **middle layer between your domain and data access logic**. It abstracts the way you store and retrieve data, giving your application a clean separation of concerns: |
|||
|
|||
* **Separation of Concerns:** Business logic doesn’t depend on the database. |
|||
* **Easier Testing:** You can replace the repository with a fake or mock during unit tests. |
|||
* **Flexibility:** You can switch data sources (e.g., from SQL to MongoDB) without touching business logic. |
|||
|
|||
Let’s see how this works with a simple example. |
|||
|
|||
## A Simple Example with Product Repository |
|||
|
|||
Imagine we’re building a small e-commerce app. We’ll start by defining a repository interface for managing products. |
|||
|
|||
You can find the complete sample code in this GitHub repository: |
|||
|
|||
https://github.com/m-aliozkaya/RepositoryPattern |
|||
|
|||
### Domain model and context |
|||
|
|||
We start with a single entity and a matching `DbContext`. |
|||
|
|||
`Product.cs` |
|||
|
|||
```csharp |
|||
using System.ComponentModel.DataAnnotations; |
|||
|
|||
namespace RepositoryPattern.Web.Models; |
|||
|
|||
public class Product |
|||
{ |
|||
public int Id { get; set; } |
|||
|
|||
[Required, StringLength(64)] |
|||
public string Name { get; set; } = string.Empty; |
|||
|
|||
[Range(0, double.MaxValue)] |
|||
public decimal Price { get; set; } |
|||
|
|||
[StringLength(256)] |
|||
public string? Description { get; set; } |
|||
|
|||
public int Stock { get; set; } |
|||
} |
|||
``` |
|||
|
|||
`"AppDbContext.cs` |
|||
|
|||
```csharp |
|||
using Microsoft.EntityFrameworkCore; |
|||
using RepositoryPattern.Web.Models; |
|||
|
|||
namespace RepositoryPattern.Web.Data; |
|||
|
|||
public class AppDbContext(DbContextOptions<AppDbContext> options) : DbContext(options) |
|||
{ |
|||
public DbSet<Product> Products => Set<Product>(); |
|||
} |
|||
``` |
|||
|
|||
### Generic repository contract and base class |
|||
|
|||
All entities share the same CRUD needs, so we define a generic interface and an EF Core implementation. |
|||
|
|||
`Repositories/IRepository.cs` |
|||
|
|||
```csharp |
|||
using System.Linq.Expressions; |
|||
|
|||
namespace RepositoryPattern.Web.Repositories; |
|||
|
|||
public interface IRepository<TEntity> where TEntity : class |
|||
{ |
|||
Task<TEntity?> GetByIdAsync(int id, CancellationToken cancellationToken = default); |
|||
Task<List<TEntity>> GetAllAsync(CancellationToken cancellationToken = default); |
|||
Task<List<TEntity>> GetListAsync(Expression<Func<TEntity, bool>> predicate, CancellationToken cancellationToken = default); |
|||
Task AddAsync(TEntity entity, CancellationToken cancellationToken = default); |
|||
Task UpdateAsync(TEntity entity, CancellationToken cancellationToken = default); |
|||
Task DeleteAsync(int id, CancellationToken cancellationToken = default); |
|||
} |
|||
``` |
|||
|
|||
`Repositories/EfRepository.cs` |
|||
|
|||
```csharp |
|||
using Microsoft.EntityFrameworkCore; |
|||
using RepositoryPattern.Web.Data; |
|||
|
|||
namespace RepositoryPattern.Web.Repositories; |
|||
|
|||
public class EfRepository<TEntity>(AppDbContext context) : IRepository<TEntity> |
|||
where TEntity : class |
|||
{ |
|||
protected readonly AppDbContext Context = context; |
|||
|
|||
public virtual async Task<TEntity?> GetByIdAsync(int id, CancellationToken cancellationToken = default) |
|||
=> await Context.Set<TEntity>().FindAsync([id], cancellationToken); |
|||
|
|||
public virtual async Task<List<TEntity>> GetAllAsync(CancellationToken cancellationToken = default) |
|||
=> await Context.Set<TEntity>().AsNoTracking().ToListAsync(cancellationToken); |
|||
|
|||
public virtual async Task<List<TEntity>> GetListAsync( |
|||
System.Linq.Expressions.Expression<Func<TEntity, bool>> predicate, |
|||
CancellationToken cancellationToken = default) |
|||
=> await Context.Set<TEntity>() |
|||
.AsNoTracking() |
|||
.Where(predicate) |
|||
.ToListAsync(cancellationToken); |
|||
|
|||
public virtual async Task AddAsync(TEntity entity, CancellationToken cancellationToken = default) |
|||
{ |
|||
await Context.Set<TEntity>().AddAsync(entity, cancellationToken); |
|||
await Context.SaveChangesAsync(cancellationToken); |
|||
} |
|||
|
|||
public virtual async Task UpdateAsync(TEntity entity, CancellationToken cancellationToken = default) |
|||
{ |
|||
Context.Set<TEntity>().Update(entity); |
|||
await Context.SaveChangesAsync(cancellationToken); |
|||
} |
|||
|
|||
public virtual async Task DeleteAsync(int id, CancellationToken cancellationToken = default) |
|||
{ |
|||
var entity = await GetByIdAsync(id, cancellationToken); |
|||
if (entity is null) |
|||
{ |
|||
return; |
|||
} |
|||
|
|||
Context.Set<TEntity>().Remove(entity); |
|||
await Context.SaveChangesAsync(cancellationToken); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
Reads use `AsNoTracking()` to avoid tracking overhead, while write methods call `SaveChangesAsync` to keep the sample straightforward. |
|||
|
|||
### Product-specific repository |
|||
|
|||
Products need one extra query: list the items that are almost out of stock. We extend the generic repository with a dedicated interface and implementation. |
|||
|
|||
`Repositories/IProductRepository.cs` |
|||
|
|||
```csharp |
|||
using RepositoryPattern.Web.Models; |
|||
|
|||
namespace RepositoryPattern.Web.Repositories; |
|||
|
|||
public interface IProductRepository : IRepository<Product> |
|||
{ |
|||
Task<List<Product>> GetLowStockProductsAsync(int threshold, CancellationToken cancellationToken = default); |
|||
} |
|||
``` |
|||
|
|||
`Repositories/ProductRepository.cs` |
|||
|
|||
```csharp |
|||
using Microsoft.EntityFrameworkCore; |
|||
using RepositoryPattern.Web.Data; |
|||
using RepositoryPattern.Web.Models; |
|||
|
|||
namespace RepositoryPattern.Web.Repositories; |
|||
|
|||
public class ProductRepository(AppDbContext context) : EfRepository<Product>(context), IProductRepository |
|||
{ |
|||
public Task<List<Product>> GetLowStockProductsAsync(int threshold, CancellationToken cancellationToken = default) => |
|||
Context.Products |
|||
.AsNoTracking() |
|||
.Where(product => product.Stock <= threshold) |
|||
.OrderBy(product => product.Stock) |
|||
.ToListAsync(cancellationToken); |
|||
} |
|||
``` |
|||
|
|||
### 🧩 A Note on Unit of Work |
|||
|
|||
The Repository Pattern is often used together with the **Unit of Work** pattern to manage transactions efficiently. |
|||
|
|||
> 💡 *If you want to dive deeper into the Unit of Work pattern, check out our separate blog post dedicated to that topic. https://abp.io/community/articles/lv4v2tyf |
|||
|
|||
### Service layer and controller |
|||
|
|||
Controllers depend on a service, and the service depends on the repository. That keeps HTTP logic and data logic separate. |
|||
|
|||
`Services/ProductService.cs` |
|||
|
|||
```csharp |
|||
using RepositoryPattern.Web.Models; |
|||
using RepositoryPattern.Web.Repositories; |
|||
|
|||
namespace RepositoryPattern.Web.Services; |
|||
|
|||
public class ProductService(IProductRepository productRepository) |
|||
{ |
|||
private readonly IProductRepository _productRepository = productRepository; |
|||
|
|||
public Task<List<Product>> GetProductsAsync(CancellationToken cancellationToken = default) => |
|||
_productRepository.GetAllAsync(cancellationToken); |
|||
|
|||
public Task<List<Product>> GetLowStockAsync(int threshold, CancellationToken cancellationToken = default) => |
|||
_productRepository.GetLowStockProductsAsync(threshold, cancellationToken); |
|||
|
|||
public Task<Product?> GetByIdAsync(int id, CancellationToken cancellationToken = default) => |
|||
_productRepository.GetByIdAsync(id, cancellationToken); |
|||
|
|||
public Task CreateAsync(Product product, CancellationToken cancellationToken = default) => |
|||
_productRepository.AddAsync(product, cancellationToken); |
|||
|
|||
public Task UpdateAsync(Product product, CancellationToken cancellationToken = default) => |
|||
_productRepository.UpdateAsync(product, cancellationToken); |
|||
|
|||
public Task DeleteAsync(int id, CancellationToken cancellationToken = default) => |
|||
_productRepository.DeleteAsync(id, cancellationToken); |
|||
} |
|||
``` |
|||
|
|||
`Controllers/ProductsController.cs` |
|||
|
|||
```csharp |
|||
using Microsoft.AspNetCore.Mvc; |
|||
using RepositoryPattern.Web.Models; |
|||
using RepositoryPattern.Web.Services; |
|||
|
|||
namespace RepositoryPattern.Web.Controllers; |
|||
|
|||
public class ProductsController(ProductService productService) : Controller |
|||
{ |
|||
private readonly ProductService _productService = productService; |
|||
|
|||
public async Task<IActionResult> Index(CancellationToken cancellationToken) |
|||
{ |
|||
const int lowStockThreshold = 5; |
|||
var products = await _productService.GetProductsAsync(cancellationToken); |
|||
var lowStock = await _productService.GetLowStockAsync(lowStockThreshold, cancellationToken); |
|||
|
|||
return View(new ProductListViewModel(products, lowStock, lowStockThreshold)); |
|||
} |
|||
|
|||
// remaining CRUD actions call through ProductService in the same way |
|||
} |
|||
``` |
|||
|
|||
The controller never reaches for `AppDbContext`. Every operation travels through the service, which keeps tests simple and makes future refactors easier. |
|||
|
|||
### Dependency registration and seeding |
|||
|
|||
The last step is wiring everything up in `Program.cs`. |
|||
|
|||
```csharp |
|||
builder.Services.AddDbContext<AppDbContext>(options => |
|||
options.UseInMemoryDatabase("ProductsDb")); |
|||
builder.Services.AddScoped(typeof(IRepository<>), typeof(EfRepository<>)); |
|||
builder.Services.AddScoped<IProductRepository, ProductRepository>(); |
|||
builder.Services.AddScoped<ProductService>(); |
|||
``` |
|||
|
|||
The sample also seeds three products so the list page shows data on first run. |
|||
|
|||
Run the site with: |
|||
|
|||
```powershell |
|||
dotnet run --project RepositoryPattern.Web |
|||
``` |
|||
|
|||
## How ABP approaches the same idea |
|||
|
|||
ABP includes generic repositories by default (`IRepository<TEntity, TKey>`), so you often skip writing the implementation layer shown above. You inject the interface into an application service, call methods like `InsertAsync` or `CountAsync`, and ABP’s Unit of Work handles the transaction. When you need custom queries, you can still derive from `EfCoreRepository<TEntity, TKey>` and add them. |
|||
|
|||
For more details, check out the official ABP documentation on repositories: https://abp.io/docs/latest/framework/architecture/domain-driven-design/repositories |
|||
|
|||
### Closing note |
|||
|
|||
This setup keeps data access tidy without being heavy. Start with the generic repository, add small extensions per entity, pass everything through services, and register the dependencies once. Whether you hand-code it or let ABP supply the repository, the structure stays the same and your controllers remain clean. |
|||
@ -0,0 +1,173 @@ |
|||
# Announcing .NET Aspire Integration for ABP Microservice Template |
|||
|
|||
We are excited to announce the integration of **.NET Aspire** into the ABP microservice solution, available starting with **ABP Studio v2.0.0**. This integration brings a unified development experience for building, running, debugging, and deploying distributed applications. With Aspire, you can now orchestrate your entire microservice ecosystem with a single command, eliminating complex configurations and making local development effortless. |
|||
|
|||
## What is .NET Aspire? |
|||
|
|||
[Aspire](https://aspire.dev/get-started/what-is-aspire/) is a cloud-ready stack designed to streamline the development of distributed applications. It provides: |
|||
|
|||
- **Orchestration**: A code-first approach to defining and running distributed applications, managing dependencies, and launch order. |
|||
- **Integrations**: Pre-built components for common services (databases, caches, message brokers) with automatic configuration. |
|||
- **Tooling**: A developer dashboard for real-time monitoring of logs, traces, metrics, and resource health. |
|||
- **Service Discovery**: Automatic service-to-service communication without hardcoded endpoints. |
|||
- **Observability**: Built-in OpenTelemetry support for distributed tracing, metrics, and structured logging. |
|||
|
|||
## How Does It Work with ABP? |
|||
|
|||
When you enable .NET Aspire in an ABP microservice solution, you get a fully integrated development experience where: |
|||
|
|||
- All microservices, gateways, and applications are orchestrated through a single entry point (AppHost). |
|||
- Infrastructure containers (databases, Redis, RabbitMQ, Elasticsearch, etc.) are managed as code. |
|||
- OpenTelemetry, health checks, and service discovery are automatically configured for all projects via the shared ServiceDefaults project. |
|||
|
|||
## Enabling Aspire in Your Solution |
|||
|
|||
When creating a new microservice solution via ABP Studio: |
|||
|
|||
1. In the solution creation wizard, look for the **".NET Aspire Integration"** step. |
|||
2. Toggle the option to **enable .NET Aspire**. |
|||
3. Complete the wizard—Aspire projects will be generated along with your solution. |
|||
|
|||
 |
|||
|
|||
## Solution Structure Changes |
|||
|
|||
When Aspire is enabled, two additional projects are added to your solution: |
|||
|
|||
 |
|||
|
|||
### AppHost (Orchestrator) |
|||
|
|||
[`AppHost`](https://aspire.dev/get-started/app-host/) is the .NET Aspire orchestrator project that declares all resources (services, databases, containers, applications) and their dependencies in C# code. It provides: |
|||
|
|||
- **Centralized orchestration**: Start your entire microservice ecosystem with a single command. |
|||
- **Code-first infrastructure**: Databases, Redis, RabbitMQ, Elasticsearch, and observability tools are defined programmatically. |
|||
- **Dependency management**: Services start in the correct order using `WaitFor()` declarations. |
|||
- **Automatic configuration**: Connection strings, endpoints, and environment variables are injected automatically. |
|||
|
|||
### ServiceDefaults |
|||
|
|||
[`ServiceDefaults`](https://aspire.dev/fundamentals/service-defaults/) is a shared library that provides common cloud-native configuration for all projects in the solution. Every service uses the same observability, health check, and resilience patterns. |
|||
|
|||
| Feature | Description | |
|||
|---------|-------------| |
|||
| OpenTelemetry | Tracing, metrics, and structured logging with automatic instrumentation | |
|||
| Health Checks | `/health` and `/alive` endpoints for Kubernetes-style probes | |
|||
| Service Discovery | Automatic resolution of service endpoints | |
|||
| HTTP Resilience | Retry policies, timeouts, and circuit breakers for HTTP clients | |
|||
|
|||
## Running the Solution with Aspire |
|||
|
|||
Running your microservice solution has never been easier: |
|||
|
|||
1. Open **Solution Runner** in ABP Studio. |
|||
2. Select the **Aspire** profile. |
|||
3. Run `AppHost`. |
|||
|
|||
 |
|||
|
|||
AppHost automatically: |
|||
|
|||
- Starts all infrastructure containers (database, Redis, RabbitMQ, Elasticsearch, etc.). |
|||
- Launches all microservices, gateways, and applications in dependency order. |
|||
- Injects connection strings and environment variables. |
|||
- Opens the Aspire Dashboard for monitoring. |
|||
|
|||
 |
|||
|
|||
## Aspire Dashboard |
|||
|
|||
The Aspire Dashboard provides real-time tracking of your application's state. It enables you to monitor logs, traces, metrics, and environment configurations in an intuitive UI. |
|||
|
|||
 |
|||
|
|||
### Key Dashboard Features |
|||
|
|||
#### Console Logs |
|||
|
|||
Display console logs from all resources in real-time. Filter by resource and log level to quickly find relevant information during development and debugging. |
|||
|
|||
 |
|||
|
|||
#### Structured Logs |
|||
|
|||
View structured logs from all resources with advanced filtering capabilities. Search and filter logs by resource, log level, timestamp, and custom properties. |
|||
|
|||
 |
|||
|
|||
#### Distributed Traces |
|||
|
|||
Explore distributed traces across your microservices to understand request flows and identify performance bottlenecks. |
|||
|
|||
 |
|||
|
|||
#### Metrics |
|||
|
|||
Monitor real-time metrics including HTTP requests, response times, garbage collection, memory usage, and custom metrics. |
|||
|
|||
 |
|||
|
|||
## Pre-Configured Observability Tools |
|||
|
|||
AppHost comes with pre-configured observability and management tools: |
|||
|
|||
### Grafana |
|||
|
|||
Visualization and analytics platform for monitoring metrics with interactive dashboards. |
|||
|
|||
 |
|||
|
|||
### Jaeger |
|||
|
|||
Distributed tracing system to monitor and troubleshoot problems across microservices. |
|||
|
|||
 |
|||
|
|||
### Kibana |
|||
|
|||
Visualization tool for Elasticsearch data with search and data visualization capabilities for logs. |
|||
|
|||
 |
|||
|
|||
### Prometheus |
|||
|
|||
Monitoring and alerting toolkit that collects and stores metrics as time series data. |
|||
|
|||
 |
|||
|
|||
### RabbitMQ Management |
|||
|
|||
Web-based interface for managing and monitoring the RabbitMQ message broker. |
|||
|
|||
 |
|||
|
|||
### Redis Insight |
|||
|
|||
Visual tool for Redis that allows you to browse data, run commands, and monitor performance. |
|||
|
|||
 |
|||
|
|||
### Database Admin Tools |
|||
|
|||
The database management admin tool varies by database type: |
|||
|
|||
| Database | Tool | |
|||
|----------|------| |
|||
| SQL Server | DBeaver CloudBeaver | |
|||
| MySQL | phpMyAdmin | |
|||
| PostgreSQL | pgAdmin | |
|||
| MongoDB | Mongo Express | |
|||
|
|||
 |
|||
|
|||
## Get Started Today |
|||
|
|||
Ready to experience the power of .NET Aspire with ABP? Create a new microservice solution in ABP Studio and enable the .NET Aspire integration option. For detailed documentation, visit our [.NET Aspire Integration documentation](https://abp.io/docs/latest/solution-templates/microservice/aspire-integration). |
|||
|
|||
To learn more about .NET Aspire, visit: [https://aspire.dev](https://aspire.dev/get-started/what-is-aspire/) |
|||
|
|||
We are excited to bring this integration to you and can't wait to hear your feedback. If you have any questions or suggestions, please drop a comment below. |
|||
|
|||
Happy coding! |
|||
|
|||
**The Volosoft Team** |
|||
|
After Width: | Height: | Size: 75 KiB |
|
After Width: | Height: | Size: 52 KiB |
|
After Width: | Height: | Size: 141 KiB |
|
After Width: | Height: | Size: 45 KiB |
|
After Width: | Height: | Size: 56 KiB |
|
After Width: | Height: | Size: 61 KiB |
|
After Width: | Height: | Size: 56 KiB |
|
After Width: | Height: | Size: 67 KiB |
|
After Width: | Height: | Size: 81 KiB |
|
After Width: | Height: | Size: 63 KiB |
|
After Width: | Height: | Size: 104 KiB |
|
After Width: | Height: | Size: 98 KiB |
|
After Width: | Height: | Size: 57 KiB |
|
After Width: | Height: | Size: 82 KiB |
|
After Width: | Height: | Size: 29 KiB |
|
After Width: | Height: | Size: 26 KiB |
@ -0,0 +1,88 @@ |
|||
# 5 Things You Should Keep in Mind When Deploying to a Clustered Environment |
|||
|
|||
Let’s be honest — moving from a single server to a cluster sounds simple on paper. |
|||
You just add a few more machines, right? |
|||
In practice, it’s the moment when small architectural mistakes start to grow legs. |
|||
Below are a few things that experienced engineers usually double-check before pressing that “Deploy” button. |
|||
|
|||
--- |
|||
|
|||
## 1️⃣ Managing State the Right Way |
|||
|
|||
Each request in a cluster might hit a different machine. |
|||
If your application keeps user sessions or cache in memory, that data probably won’t exist on the next node. |
|||
That’s why many teams decide to push state out of the app itself. |
|||
|
|||
 |
|||
|
|||
**A few real-world tips:** |
|||
- Keep sessions in **Redis** or something similar instead of local memory. |
|||
- Design endpoints so they don’t rely on earlier requests. |
|||
- Don’t assume the same server will handle two requests in a row — it rarely does. |
|||
|
|||
--- |
|||
|
|||
## 2️⃣ Shared Files and Where to Put Them |
|||
|
|||
Uploading files to local disk? That’s going to hurt in a cluster. |
|||
Other nodes can’t reach those files, and you’ll spend hours wondering why images disappear. |
|||
|
|||
 |
|||
|
|||
**Better habits:** |
|||
- Push uploads to **S3**, **Azure Blob**, or **Google Cloud Storage**. |
|||
- Send logs to a shared location instead of writing to local files. |
|||
- Keep environment configs in a central place so each node starts with the same settings. |
|||
|
|||
--- |
|||
|
|||
## 3️⃣ Database Connections Aren’t Free |
|||
|
|||
Every node opens its own database connections. |
|||
Ten nodes with twenty connections each — that’s already two hundred open sessions. |
|||
The database might not love that. |
|||
|
|||
 |
|||
|
|||
**What helps:** |
|||
- Put a cap on your connection pools. |
|||
- Avoid keeping transactions open for too long. |
|||
- Tune indexes and queries before scaling horizontally. |
|||
|
|||
--- |
|||
|
|||
## 4️⃣ Logging and Observability Matter More Than You Think |
|||
|
|||
When something breaks in a distributed system, it’s never obvious which server was responsible. |
|||
That’s why observability isn’t optional anymore. |
|||
|
|||
 |
|||
|
|||
**Consider this:** |
|||
- Stream logs to **ELK**, **Datadog**, or **Grafana Loki**. |
|||
- Add a **trace ID** to every incoming request and propagate it across services. |
|||
- Watch key metrics with **Prometheus** and visualize them in Grafana dashboards. |
|||
|
|||
--- |
|||
|
|||
## 5️⃣ Background Jobs and Message Queues |
|||
|
|||
If more than one node runs the same job, you might process the same data twice — or delete something by mistake. |
|||
You don’t want that kind of excitement in production. |
|||
|
|||
 |
|||
|
|||
**A few precautions:** |
|||
- Use a **distributed lock** or **leader election** system. |
|||
- Make jobs **idempotent**, so running them twice doesn’t break data. |
|||
- Centralize queue consumers or use a proper task scheduler. |
|||
|
|||
--- |
|||
|
|||
## Wrapping Up |
|||
|
|||
Deploying to a cluster isn’t only about scaling up — it’s about staying stable when you do. |
|||
Systems that handle state, logging, and background work correctly tend to age gracefully. |
|||
Everything else eventually learns the hard way. |
|||
|
|||
> A cluster doesn’t fix design flaws — it magnifies them. |
|||
|
After Width: | Height: | Size: 118 KiB |
|
After Width: | Height: | Size: 68 KiB |
|
After Width: | Height: | Size: 718 KiB |
|
After Width: | Height: | Size: 75 KiB |
@ -0,0 +1,27 @@ |
|||
# 5 Things You Should Keep in Mind When Deploying to a Clustered Environment |
|||
|
|||
Let’s be honest — moving from a single server to a cluster sounds simple on paper. |
|||
You just add a few more machines, right? |
|||
In practice, it’s the moment when small architectural mistakes start to grow legs. |
|||
Below are a few things that experienced engineers usually double-check before pressing that “Deploy” button. |
|||
|
|||
--- |
|||
|
|||
## 1️⃣ Managing State the Right Way |
|||
--- |
|||
|
|||
## 2️⃣ Shared Files and Where to Put Them |
|||
--- |
|||
|
|||
## 3️⃣ Database Connections Aren’t Free |
|||
--- |
|||
|
|||
## 4️⃣ Logging and Observability Matter More Than You Think |
|||
--- |
|||
|
|||
## 5️⃣ Background Jobs and Message Queues |
|||
--- |
|||
|
|||
 |
|||
|
|||
👉 Read the full guide here: [5 Things You Should Keep in Mind When Deploying to a Clustered Environment](https://abp.io/community/articles/) |
|||
|
After Width: | Height: | Size: 67 KiB |
|
After Width: | Height: | Size: 87 KiB |
|
After Width: | Height: | Size: 40 KiB |
|
After Width: | Height: | Size: 504 KiB |
@ -0,0 +1,98 @@ |
|||
# **Return Code vs Exceptions: Which One is Better?** |
|||
|
|||
Alright, so this debate pops up every few months on dev subreddits and forums |
|||
|
|||
> *Should you use return codes or exceptions for error handling?* |
|||
|
|||
And honestly, there’s no %100 right answer here! Both have pros/cons, and depending on the language or context, one might make more sense than the other. Let’s see... |
|||
|
|||
------ |
|||
|
|||
## 1. Return Codes --- Said to be "Old School Way" --- |
|||
|
|||
Return codes (like `0` for success, `-1` for failure, etc.) are the OG method. You mostly see them everywhere in C and C++. |
|||
They’re super explicit, the function literally *returns* the result of the operation. |
|||
|
|||
### ➕ Advantages of returning codes: |
|||
|
|||
- You *always* know when something went wrong |
|||
- No hidden control flow — what you see is what you get |
|||
- Usually faster (no stack unwinding, no exception overhead) |
|||
- Easy to use in systems programming, embedded stuff, or performance-critical code |
|||
|
|||
### ➖ Disadvantages of returning codes: |
|||
|
|||
- It’s easy to forget to check the return value (and boom, silent failure 😬) |
|||
- Makes code noisy... Everry function call followed by `if (result != SUCCESS)` gets annoying |
|||
- No stack trace or context unless you manually build one |
|||
|
|||
**For example:** |
|||
|
|||
```csharp |
|||
try |
|||
{ |
|||
await SendEmailAsync(); |
|||
} |
|||
catch (Exception e) |
|||
{ |
|||
Log.Exception(e.ToString()); |
|||
return -1; |
|||
} |
|||
``` |
|||
|
|||
Looks fine… until you forget one of those `if` conditions somewhere. |
|||
|
|||
------ |
|||
|
|||
## 2. Exceptions --- The Fancy & Modern Way --- |
|||
|
|||
Exceptions came in later, mostly with higher-level languages like Java, C#, and Python. |
|||
The idea is that you *throw* an error and handle it *somewhere else*. |
|||
|
|||
### ➕ Advantages of throwing exceptions: |
|||
|
|||
- Cleaner code... You can focus on the happy path and handle errors separately |
|||
- Can carry detailed info (stack traces, messages, inner exceptions...) |
|||
- Easier to handle complex error propagation |
|||
|
|||
### ➖ Disadvantages of throwing exceptions: |
|||
|
|||
- Hidden control flow — you don’t always see what might throw |
|||
- Performance hit (esp. in tight loops or low-level systems) |
|||
- Overused in some codebases (“everything throws everything”) |
|||
|
|||
**Example:** |
|||
|
|||
```csharp |
|||
try |
|||
{ |
|||
await SendEmailAsync(); |
|||
} |
|||
catch (Exception e) |
|||
{ |
|||
Log.Exception(e.ToString()); |
|||
throw e; |
|||
} |
|||
``` |
|||
|
|||
Way cleaner, but if `SendEmailAsync()` is deep in your call stack and it fails, it can be tricky to know exactly what went wrong unless you log properly. |
|||
|
|||
------ |
|||
|
|||
### And Which One’s Better? ⚖️ |
|||
|
|||
Depends on what you’re building. |
|||
|
|||
- **Low-level systems, drivers, real-time stuff 👉 Return codes.** Performance and control matter more. |
|||
- **Application-level, business logic, or high-level APIs 👉 Exceptions.** Cleaner and easier to maintain. |
|||
|
|||
And honestly, mixing both sometimes makes sense. |
|||
For example, you can use return codes internally and exceptions at the boundary of your API to surface meaningful errors to the user. |
|||
|
|||
------ |
|||
|
|||
### Conclusion |
|||
|
|||
Return codes = simple, explicit, but messy.t |
|||
Exceptions = clean, powerful, but can bite you. |
|||
Use what fits your project and your team’s sanity level 😅. |
|||
|
After Width: | Height: | Size: 5.1 KiB |
|
After Width: | Height: | Size: 52 KiB |
|
After Width: | Height: | Size: 107 KiB |
@ -0,0 +1,112 @@ |
|||
# UI & UX Trends That Will Shape 2026 |
|||
|
|||
Cinematic, gamified, high-wow-factor websites with scroll-to-play videos or scroll-to-tell stories are wonderful to experience, but you won't find these trends in this article. If you're interested in design trends directly related to the software world, such as **performance**, **accessibility**, **understandability**, and **efficiency**, grab a cup of coffee and enjoy. |
|||
|
|||
As we approach the end of 2025, I'd like to share with you the most important user interface and user experience design trends that have become more of a **toolkit** than a trend, and that continue to evolve and become a part of our lives. I predict we'll see a lot of them in 2026\. |
|||
|
|||
## 1\. Simplicity and Speed |
|||
|
|||
Designing understandable and readable applications is becoming far more important than designing in line with trends and fashion. In the software and business world, preferences are shifting more and more toward the **right design** over the cool design. As designers developing a product whose direct target audience is software developers, we design our products for the designers' enjoyment, but for the **end user's ease of use**. |
|||
|
|||
Users no longer care so much about the flashiness of a website. True converts are primarily interested in your product, service, or content. What truly matters to them is how easily and quickly they can access the information they're looking for. |
|||
|
|||
More users, more sales, better promotion, and a higher conversion rate... The elements that serve these goals are optimized solutions and thoughtful details in our designs, more than visual displays. |
|||
|
|||
If the "loading" icon appears too often on your digital product, you might not be doing it right. If you fail to optimize speed, the temporary effect of visual displays won't be enough to convert potential users into customers. Remember, the moment people start waiting, you've lost at least half of them. |
|||
|
|||
## 2\. Dark Mode \- Still, and Forever |
|||
 |
|||
|
|||
Dark Mode is no longer an option; it's a **standard**. It's become a necessity, not a choice, especially for users who spend hours staring at screens and are accustomed to dark themes in code editors and terminals. However, the approach to dark mode isn't simply about inverting colors; it's much deeper than that. The key is managing contrast and depth. |
|||
|
|||
The layer hierarchy established in a light-colored design doesn't lose its impact when switched to dark mode. The colors, shadows, highlights, and contrasting elements used to create an **easily perceivable hierarchy** should be carefully considered for each mode. Our [LeptonX theme](https://leptontheme.com/)'s Light, Dark, Semi-dark, and System modes offer valuable insights you might want to explore. |
|||
|
|||
You might also want to take a look at the dark and light modes we designed with these elements in mind in [ABP Studio](https://abp.io/get-started) and the [ABP.io Documents page](https://abp.io/docs/latest/). |
|||
|
|||
## 3\. Bento Grid \- A Timeless Trend |
|||
 |
|||
|
|||
People don't read your website; they **scan** it. |
|||
|
|||
Bento Grid, an indispensable trend for designers looking to manage their attention, looks set to remain a staple in 2026, just as it was in 2025\. No designer should ignore the fact that many tech giants, especially Apple and Samsung, are still using bento grids on their websites. The bento grid appears not only on websites but also in operating systems, VR headset interfaces, game console interfaces, and game designs. |
|||
|
|||
The golden rule is **contrast** and **balance**. |
|||
|
|||
The attractiveness and effectiveness of bento designs depend on certain factors you should consider when implementing them. If you ignore these rules, even with a proven method like bento, you can still alienate users. |
|||
|
|||
The bento grid is one of the best ways to display different types of content inclusively. When used correctly, it's also a great way to manipulate reading order, guiding the user's eye. Improper contrast and hierarchy can also create a negative experience. Designers should use this to guide the reader's eye: "Read here first, then read here." |
|||
|
|||
When creating a bento, you inherently have to sacrifice some of your "whitespace." This design has many elements for the user to focus on, and it actually strays from our first point, "Simplicity". Bento design, whose boundaries are drawn from the outset and independent of content, requires care not to include more or less than what is necessary. Too much content makes it boring; too little content makes it very close to meaningless. |
|||
|
|||
Bento grids should aim for a balanced design by using both simple text and sophisticated visuals. This visual can be an illustration, a video that starts playing when hovered over, a static image, or a large title. Only one or two cards on the screen at a time should have attention. |
|||
|
|||
## 4\. Larger Fonts, High Readability |
|||
 |
|||
|
|||
Large fonts have been a trend for several years, and it seems web designers are becoming more and more bold. The increasing preference for larger fonts every year is a sign that this trend will continue into 2026\. This trend is about more than just using large font sizes in headlines. |
|||
|
|||
Creating a cohesive typographic scale and proper line height and letter spacing are critical elements to consider when creating this trend. As the font size increases, line height should decrease, and the space between letters should be narrower. |
|||
|
|||
The browser default font size, which we used to see in body text and paragraphs and has now become standard, is 16 pixels. In the last few years, we've started seeing body font sizes of 17 or 18 pixels more frequently. The increasing importance of readability every year makes this more common. Font sizes in rem values, rather than px, provide the most efficient results. |
|||
|
|||
## 5\. Micro Animations |
|||
|
|||
Unless you're a web design agency designing a website to impress potential clients, you should avoid excessive changes, including excessive image changes during scrolling, and scroll direction changes. There's still room for oversized images and scroll animations. But be sure to create the visuals yourself. |
|||
|
|||
The trend I'm talking about here is **micro animations**, not macro ones. Small movements, not large ones. |
|||
|
|||
The animation approach of 2025 is **functional** and **performance-sensitive**. |
|||
|
|||
Microanimations exist to provide immediate feedback to the user. Instant feedback, like a button's shadow increasing when hovered over, a button's slight collapse when clicked, or a "Save" icon changing to a "Confirm" icon when saving data, keeps your designs alive. |
|||
|
|||
We see the real impact of the micro-animation trend in static, non-action visuals. The use of non-button elements in your designs, accentuated by micro-movements such as scrolling or hovering, seems poised to continue to create macro effects in 2026\. |
|||
|
|||
## 6\. Real Images and Human-like Touches |
|||
|
|||
People quickly spot a fake. It's very difficult to convince a user who visits your website for the first time and doesn't trust you. **First impressions** matter. |
|||
|
|||
Real photographs, actual product screenshots, and brand-specific illustrations will continue to be among the elements we want to see in **trust-focused** designs in 2026\. |
|||
|
|||
In addition to flawless work done by AI, vivid, real-life visuals, accompanied by deliberate imperfections, hand-drawn details, or designed products that convey the message, "A human made this site\!", will continue to feel warmer and more welcoming. |
|||
|
|||
The human touch is evident not only in the visuals but also in your **content and text**. |
|||
|
|||
In 2026, you'll need more **human-like touches** that will make your design stand out among the thousands of similar websites rapidly generated by AI. |
|||
|
|||
## 7\. Accessibility \- No Longer an Option, But a Legal and Ethical Obligation |
|||
|
|||
Accessibility, once considered a nice-to-do thing in recent years, is now becoming a **necessity** in 2026 and beyond. Global regulations like the European Accessibility Act require all digital products to comply with WCAG standards. |
|||
|
|||
All design and software improvements you make to ensure end users can fully perform their tasks in your products, regardless of their temporary or permanent disabilities, should be viewed as ethical and commercial requirements, not as a requirement to comply with these standards. |
|||
|
|||
The foundation of accessibility in design is to use semantic HTML for screen readers, provide full keyboard control of all interactive elements, and clearly communicate the roles of complex components to the development team. |
|||
|
|||
## 8\. Intentional Friction |
|||
|
|||
Steve Krug, the father of UX design, started the trend of designing everything at a hyper-usable level with his book "Don't Make Me Think." As web designers, we've embraced this idea so much that all we care about is getting the user to their destination in the shortest possible scenario and as quickly as possible. This has required so many understandability measures that, after a while, it's starting to feel like fooling the user. |
|||
|
|||
In recent years, designers have started looking for ways to make things a little more challenging, rather than just getting the user to the result. |
|||
|
|||
When the end user visits your website, tries to understand exactly what it is at first glance, struggles a bit, and, after a little effort, becomes familiar with how your world works, they'll be more inclined to consider themselves a part of it. |
|||
|
|||
This has nothing to do with anti-usability. This philosophy is called Intentional Friction. |
|||
|
|||
This isn't a flaw; it's the pinnacle of error prevention. It's a step to prevent errors from occurring on autopilot and respects the user's ability to understand complex systems. Examples include reviewing the order summary or manually typing the project name when deleting a project on GitHub. |
|||
|
|||
## Bonus: Where Does Artificial Intelligence Fit In? |
|||
|
|||
Artificial intelligence will be an infrastructure in 2026, not a trend. |
|||
|
|||
As designers, we should leverage AI not to paint us a picture, but to make workflows more intelligent. In my opinion, this is the best use case for AI. |
|||
|
|||
AI can learn user behavior and adapt the interface accordingly. Real-time A/B testing can save us time by conducting a real-time content review. The ability to actively use AI in any area that allows you to accelerate your progress will take you a step further in your career. |
|||
|
|||
Since your users are always human, **don't be too eager** to incorporate AI-generated visuals into your design. Unless you're creating and selling a ready-made theme, you should **avoid** AI-generated visuals, random bento grids, and randomly generated content. |
|||
|
|||
You should definitely incorporate AI into your work for new content, new ideas, personal and professional development, and insights that will take your design a step further. But just as you don't design your website for designers to like, the same applies to AI. Humans, not robots, will experience your website. **AI-assisted**, not AI-generated, designs with a human touch are the trend I most expect seeing in 2026\. |
|||
|
|||
## Conclusion |
|||
|
|||
In the end, it's all fundamentally about respect for the user and their time. In 2026, our success as designers and developers will be measured not by how "cool" we are, but by how "efficient" and "reliable" a world we build for our users. |
|||
|
|||
Thank you for your time. |
|||
|
After Width: | Height: | Size: 56 KiB |
|
After Width: | Height: | Size: 54 KiB |
|
After Width: | Height: | Size: 26 KiB |
|
After Width: | Height: | Size: 10 KiB |
|
After Width: | Height: | Size: 37 KiB |
@ -0,0 +1,592 @@ |
|||
# What is That Domain Service in DDD for .NET Developers? |
|||
|
|||
When you start applying **Domain-Driven Design (DDD)** in your .NET projects, you'll quickly meet some core building blocks: **Entities**, **Value Objects**, **Aggregates**, and finally… **Domain Services**. |
|||
|
|||
But what exactly *is* a Domain Service, and when should you use one? |
|||
|
|||
Let's break it down with practical examples and ABP Framework implementation patterns. |
|||
|
|||
--- |
|||
|
|||
 |
|||
|
|||
## The Core Idea of Domain Services |
|||
|
|||
A **Domain Service** represents **a domain concept that doesn't naturally belong to a single Entity or Value Object**, but still belongs to the **domain layer** - *not* to the application or infrastructure. |
|||
|
|||
In short: |
|||
|
|||
> If your business logic doesn't fit into a single Entity, but still expresses a business rule, that's a good candidate for a Domain Service. |
|||
|
|||
|
|||
|
|||
--- |
|||
|
|||
## Example: Money Transfer Between Accounts |
|||
|
|||
Imagine a simple **banking system** where you can transfer money between accounts. |
|||
|
|||
```csharp |
|||
public class Account : AggregateRoot<Guid> |
|||
{ |
|||
public decimal Balance { get; private set; } |
|||
|
|||
// Domain model should be created in a valid state. |
|||
public Account(decimal openingBalance = 0m) |
|||
{ |
|||
if (openingBalance < 0) |
|||
throw new BusinessException("Opening balance cannot be negative."); |
|||
Balance = openingBalance; |
|||
} |
|||
|
|||
public void Withdraw(decimal amount) |
|||
{ |
|||
if (amount <= 0) |
|||
throw new BusinessException("Withdrawal amount must be positive."); |
|||
if (Balance < amount) |
|||
throw new BusinessException("Insufficient balance."); |
|||
Balance -= amount; |
|||
} |
|||
|
|||
public void Deposit(decimal amount) |
|||
{ |
|||
if (amount <= 0) |
|||
throw new BusinessException("Deposit amount must be positive."); |
|||
Balance += amount; |
|||
} |
|||
} |
|||
``` |
|||
|
|||
> In a richer domain you might introduce a `Money` value object (amount + currency + rounding rules) instead of a raw `decimal` for stronger invariants. |
|||
|
|||
--- |
|||
|
|||
## Implementing a Domain Service |
|||
|
|||
 |
|||
|
|||
```csharp |
|||
public class MoneyTransferManager : DomainService |
|||
{ |
|||
public void Transfer(Account from, Account to, decimal amount) |
|||
{ |
|||
if (from is null) throw new ArgumentNullException(nameof(from)); |
|||
if (to is null) throw new ArgumentNullException(nameof(to)); |
|||
if (ReferenceEquals(from, to)) |
|||
throw new BusinessException("Cannot transfer to the same account."); |
|||
if (amount <= 0) |
|||
throw new BusinessException("Transfer amount must be positive."); |
|||
|
|||
from.Withdraw(amount); |
|||
to.Deposit(amount); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
> **Naming Convention**: ABP suggests using the `Manager` or `Service` suffix for domain services. We typically use `Manager` suffix (e.g., `IssueManager`, `OrderManager`). |
|||
|
|||
> **Note**: This is a synchronous domain operation. The domain service focuses purely on business rules without infrastructure concerns like database access or event publishing. For cross-cutting concerns, use Application Service layer or domain events. |
|||
|
|||
--- |
|||
|
|||
## Domain Service vs. Application Service |
|||
|
|||
Here's a quick comparison: |
|||
|
|||
 |
|||
|
|||
| Layer | Responsibility | Example | |
|||
| ----------------------- | -------------------------------------------------------------------------------- | ---------------------------- | |
|||
| **Domain Service** | Pure business rule spanning entities/aggregates | `MoneyTransferManager` | |
|||
| **Application Service** | Orchestrates use cases, handles repositories, transactions, external systems | `BankAppService` | |
|||
|
|||
--- |
|||
|
|||
## The Application Service Layer |
|||
|
|||
An **Application Service** orchestrates the domain logic and handles infrastructure concerns: |
|||
|
|||
 |
|||
|
|||
```csharp |
|||
public class BankAppService : ApplicationService |
|||
{ |
|||
private readonly IRepository<Account, Guid> _accountRepository; |
|||
private readonly MoneyTransferManager _moneyTransferManager; |
|||
|
|||
public BankAppService( |
|||
IRepository<Account, Guid> accountRepository, |
|||
MoneyTransferManager moneyTransferManager) |
|||
{ |
|||
_accountRepository = accountRepository; |
|||
_moneyTransferManager = moneyTransferManager; |
|||
} |
|||
|
|||
public async Task TransferAsync(Guid fromId, Guid toId, decimal amount) |
|||
{ |
|||
var from = await _accountRepository.GetAsync(fromId); |
|||
var to = await _accountRepository.GetAsync(toId); |
|||
|
|||
_moneyTransferManager.Transfer(from, to, amount); |
|||
|
|||
await _accountRepository.UpdateAsync(from); |
|||
await _accountRepository.UpdateAsync(to); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
> **Note**: Domain services are automatically registered to Dependency Injection with a **Transient** lifetime when inheriting from `DomainService`. |
|||
|
|||
--- |
|||
|
|||
## Benefits of ABP's DomainService Base Class |
|||
|
|||
The `DomainService` base class gives you access to: |
|||
|
|||
- **Localization** (`IStringLocalizer L`) - Multi-language support for error messages |
|||
- **Logging** (`ILogger Logger`) - Built-in logger for tracking operations |
|||
- **Local Event Bus** (`ILocalEventBus LocalEventBus`) - Publish local domain events |
|||
- **Distributed Event Bus** (`IDistributedEventBus DistributedEventBus`) - Publish distributed events |
|||
- **GUID Generator** (`IGuidGenerator GuidGenerator`) - Sequential GUID generation for better database performance |
|||
- **Clock** (`IClock Clock`) - Abstraction for date/time operations |
|||
|
|||
### Example with ABP Features |
|||
|
|||
> **Important**: While domain services *can* publish domain events using the event bus, they should remain focused on business rules. Consider whether event publishing belongs in the domain service or the application service based on your consistency boundaries. |
|||
|
|||
```csharp |
|||
public class MoneyTransferredEvent |
|||
{ |
|||
public Guid FromAccountId { get; set; } |
|||
public Guid ToAccountId { get; set; } |
|||
public decimal Amount { get; set; } |
|||
} |
|||
|
|||
public class MoneyTransferManager : DomainService |
|||
{ |
|||
public async Task TransferAsync(Account from, Account to, decimal amount) |
|||
{ |
|||
if (from is null) throw new ArgumentNullException(nameof(from)); |
|||
if (to is null) throw new ArgumentNullException(nameof(to)); |
|||
if (ReferenceEquals(from, to)) |
|||
throw new BusinessException(L["SameAccountTransferNotAllowed"]); |
|||
if (amount <= 0) |
|||
throw new BusinessException(L["InvalidTransferAmount"]); |
|||
|
|||
// Log the operation |
|||
Logger.LogInformation( |
|||
"Transferring {Amount} from {From} to {To}", amount, from.Id, to.Id); |
|||
|
|||
from.Withdraw(amount); |
|||
to.Deposit(amount); |
|||
|
|||
// Publish local event for further policies (limits, notifications, audit, etc.) |
|||
await LocalEventBus.PublishAsync( |
|||
new MoneyTransferredEvent |
|||
{ |
|||
FromAccountId = from.Id, |
|||
ToAccountId = to.Id, |
|||
Amount = amount |
|||
} |
|||
); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
> **Local Events**: By default, event handlers are executed within the same Unit of Work. If an event handler throws an exception, the database transaction is rolled back, ensuring consistency. |
|||
|
|||
--- |
|||
|
|||
## Best Practices |
|||
|
|||
### 1. Keep Domain Services Pure and Focused on Business Rules |
|||
|
|||
Domain services should only contain business logic. They should not be responsible for application-level concerns like database transactions, authorization, or fetching entities from a repository. |
|||
|
|||
```csharp |
|||
// Good ✅ Pure rule: receives aggregates already loaded. |
|||
public class MoneyTransferManager : DomainService |
|||
{ |
|||
public void Transfer(Account from, Account to, decimal amount) |
|||
{ |
|||
// Business rules and coordination |
|||
from.Withdraw(amount); |
|||
to.Deposit(amount); |
|||
} |
|||
} |
|||
|
|||
// Bad ❌ Mixing application and domain concerns. |
|||
// This logic belongs in an Application Service. |
|||
public class MoneyTransferManager : DomainService |
|||
{ |
|||
private readonly IRepository<Account, Guid> _accountRepository; |
|||
|
|||
public MoneyTransferManager(IRepository<Account, Guid> accountRepository) |
|||
{ |
|||
_accountRepository = accountRepository; |
|||
} |
|||
|
|||
public async Task TransferAsync(Guid fromId, Guid toId, decimal amount) |
|||
{ |
|||
// Don't fetch entities inside a domain service. |
|||
var from = await _accountRepository.GetAsync(fromId); |
|||
var to = await _accountRepository.GetAsync(toId); |
|||
|
|||
from.Withdraw(amount); |
|||
to.Deposit(amount); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
### 2. Leverage Entity Methods First |
|||
|
|||
Always prefer encapsulating business logic within an entity's methods when the logic belongs to a single aggregate. A domain service should only be used when a business rule spans multiple aggregates. |
|||
|
|||
```csharp |
|||
// Good ✅ - Internal state change belongs in the entity |
|||
public class Account : AggregateRoot<Guid> |
|||
{ |
|||
public decimal Balance { get; private set; } |
|||
|
|||
public void Withdraw(decimal amount) |
|||
{ |
|||
if (Balance < amount) |
|||
throw new BusinessException("Insufficient balance"); |
|||
Balance -= amount; |
|||
} |
|||
} |
|||
|
|||
// Use Domain Service only when logic spans multiple aggregates |
|||
public class MoneyTransferManager : DomainService |
|||
{ |
|||
public void Transfer(Account from, Account to, decimal amount) |
|||
{ |
|||
from.Withdraw(amount); // Delegates to entity |
|||
to.Deposit(amount); // Delegates to entity |
|||
} |
|||
} |
|||
``` |
|||
|
|||
### 3. Prefer Domain Services over Anemic Entities |
|||
|
|||
Avoid placing business logic that coordinates multiple entities directly into an application service. This leads to an "Anemic Domain Model," where entities are just data bags and the business logic is scattered in application services. |
|||
|
|||
```csharp |
|||
// Bad ❌ - Business logic is in the Application Service (Anemic Domain) |
|||
public class BankAppService : ApplicationService |
|||
{ |
|||
public async Task TransferAsync(Guid fromId, Guid toId, decimal amount) |
|||
{ |
|||
var from = await _accountRepository.GetAsync(fromId); |
|||
var to = await _accountRepository.GetAsync(toId); |
|||
|
|||
// This is domain logic and should be in a Domain Service |
|||
if (ReferenceEquals(from, to)) |
|||
throw new BusinessException("Cannot transfer to the same account."); |
|||
if (amount <= 0) |
|||
throw new BusinessException("Transfer amount must be positive."); |
|||
|
|||
from.Withdraw(amount); |
|||
to.Deposit(amount); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
### 4. Use Meaningful Names |
|||
|
|||
ABP recommends naming domain services with a `Manager` or `Service` suffix based on the business concept they represent. |
|||
|
|||
```csharp |
|||
// Good ✅ |
|||
MoneyTransferManager |
|||
OrderManager |
|||
IssueManager |
|||
InventoryAllocationService |
|||
|
|||
// Bad ❌ |
|||
AccountHelper |
|||
OrderProcessor |
|||
``` |
|||
|
|||
--- |
|||
|
|||
## Advanced Example: Order Processing with Inventory Check |
|||
|
|||
Here's a more complex scenario showing domain service interaction with domain abstractions: |
|||
|
|||
```csharp |
|||
// Domain abstraction - defines contract but implementation is in infrastructure |
|||
public interface IInventoryChecker : IDomainService |
|||
{ |
|||
Task<bool> IsAvailableAsync(Guid productId, int quantity); |
|||
} |
|||
|
|||
public class OrderManager : DomainService |
|||
{ |
|||
private readonly IInventoryChecker _inventoryChecker; |
|||
|
|||
public OrderManager(IInventoryChecker inventoryChecker) |
|||
{ |
|||
_inventoryChecker = inventoryChecker; |
|||
} |
|||
|
|||
// Validates and coordinates order processing with inventory |
|||
public async Task ProcessAsync(Order order, Inventory inventory) |
|||
{ |
|||
// First pass: validate availability using domain abstraction |
|||
foreach (var item in order.Items) |
|||
{ |
|||
if (!await _inventoryChecker.IsAvailableAsync(item.ProductId, item.Quantity)) |
|||
{ |
|||
throw new BusinessException( |
|||
L["InsufficientInventory", item.ProductId]); |
|||
} |
|||
} |
|||
|
|||
// Second pass: perform reservations |
|||
foreach (var item in order.Items) |
|||
{ |
|||
inventory.Reserve(item.ProductId, item.Quantity); |
|||
} |
|||
|
|||
order.SetStatus(OrderStatus.Processing); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
> **Domain Abstractions**: The `IInventoryChecker` interface is a domain service contract. Its implementation can be in the infrastructure layer, but the contract belongs to the domain. This keeps the domain layer independent of infrastructure details while still allowing complex validations. |
|||
|
|||
> **Caution**: Always perform validation and action atomically within a single transaction to avoid race conditions (TOCTOU - Time Of Check Time Of Use). |
|||
|
|||
> **Transaction Boundaries**: When a domain service coordinates multiple aggregates, ensure the Application Service wraps the operation in a Unit of Work to maintain consistency. ABP's `[UnitOfWork]` attribute or Application Services' built-in UoW handling ensures this automatically. |
|||
|
|||
--- |
|||
|
|||
## Common Pitfalls and How to Avoid Them |
|||
|
|||
### 1. Bloated Domain Services |
|||
Don't let domain services become "god objects" that do everything. Keep them focused on a single business concept. |
|||
|
|||
```csharp |
|||
// Bad ❌ - Too many responsibilities |
|||
public class AccountManager : DomainService |
|||
{ |
|||
public void Transfer(Account from, Account to, decimal amount) { } |
|||
public void CalculateInterest(Account account) { } |
|||
public void GenerateStatement(Account account) { } |
|||
public void ValidateAddress(Account account) { } |
|||
public void SendNotification(Account account) { } |
|||
} |
|||
|
|||
// Good ✅ - Split by business concept |
|||
public class MoneyTransferManager : DomainService |
|||
{ |
|||
public void Transfer(Account from, Account to, decimal amount) { } |
|||
} |
|||
|
|||
public class InterestCalculationManager : DomainService |
|||
{ |
|||
public void Calculate(Account account) { } |
|||
} |
|||
``` |
|||
|
|||
### 2. Circular Dependencies Between Aggregates |
|||
When domain services coordinate multiple aggregates, be careful about creating circular dependencies. |
|||
|
|||
```csharp |
|||
// Consider using Domain Events instead of direct coupling |
|||
public class OrderManager : DomainService |
|||
{ |
|||
public async Task ProcessAsync(Order order) |
|||
{ |
|||
order.SetStatus(OrderStatus.Processing); |
|||
|
|||
// Instead of directly modifying Customer aggregate here, |
|||
// publish an event that CustomerManager can handle |
|||
await LocalEventBus.PublishAsync(new OrderProcessedEvent |
|||
{ |
|||
OrderId = order.Id, |
|||
CustomerId = order.CustomerId |
|||
}); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
### 3. Confusing Domain Service with Domain Event Handlers |
|||
Domain services orchestrate business operations. Domain event handlers react to state changes. Don't mix them. |
|||
|
|||
```csharp |
|||
// Domain Service - Orchestrates business logic |
|||
public class MoneyTransferManager : DomainService |
|||
{ |
|||
public async Task TransferAsync(Account from, Account to, decimal amount) |
|||
{ |
|||
from.Withdraw(amount); |
|||
to.Deposit(amount); |
|||
await LocalEventBus.PublishAsync( |
|||
new MoneyTransferredEvent |
|||
{ |
|||
FromAccountId = from.Id, |
|||
ToAccountId = to.Id, |
|||
Amount = amount |
|||
} |
|||
); |
|||
} |
|||
} |
|||
|
|||
// Domain Event Handler - Reacts to domain events |
|||
public class MoneyTransferredEventHandler : |
|||
ILocalEventHandler<MoneyTransferredEvent>, |
|||
ITransientDependency |
|||
{ |
|||
public async Task HandleEventAsync(MoneyTransferredEvent eventData) |
|||
{ |
|||
// Send notification, update analytics, etc. |
|||
} |
|||
} |
|||
``` |
|||
|
|||
--- |
|||
|
|||
## Testing Domain Services |
|||
|
|||
Domain services are easy to test because they have minimal dependencies: |
|||
|
|||
```csharp |
|||
public class MoneyTransferManager_Tests |
|||
{ |
|||
[Fact] |
|||
public void Should_Transfer_Money_Between_Accounts() |
|||
{ |
|||
// Arrange |
|||
var fromAccount = new Account(1000m); |
|||
var toAccount = new Account(500m); |
|||
var manager = new MoneyTransferManager(); |
|||
|
|||
// Act |
|||
manager.Transfer(fromAccount, toAccount, 200m); |
|||
|
|||
// Assert |
|||
fromAccount.Balance.ShouldBe(800m); |
|||
toAccount.Balance.ShouldBe(700m); |
|||
} |
|||
|
|||
[Fact] |
|||
public void Should_Throw_When_Insufficient_Balance() |
|||
{ |
|||
var fromAccount = new Account(100m); |
|||
var toAccount = new Account(500m); |
|||
var manager = new MoneyTransferManager(); |
|||
|
|||
Should.Throw<BusinessException>(() => |
|||
manager.Transfer(fromAccount, toAccount, 200m)); |
|||
} |
|||
|
|||
[Fact] |
|||
public void Should_Throw_When_Amount_Is_NonPositive() |
|||
{ |
|||
var fromAccount = new Account(100m); |
|||
var toAccount = new Account(100m); |
|||
var manager = new MoneyTransferManager(); |
|||
|
|||
Should.Throw<BusinessException>(() => |
|||
manager.Transfer(fromAccount, toAccount, 0m)); |
|||
Should.Throw<BusinessException>(() => |
|||
manager.Transfer(fromAccount, toAccount, -5m)); |
|||
} |
|||
|
|||
[Fact] |
|||
public void Should_Throw_When_Same_Account() |
|||
{ |
|||
var account = new Account(100m); |
|||
var manager = new MoneyTransferManager(); |
|||
|
|||
Should.Throw<BusinessException>(() => |
|||
manager.Transfer(account, account, 10m)); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
### Integration Testing with ABP Test Infrastructure |
|||
|
|||
```csharp |
|||
public class MoneyTransferManager_IntegrationTests : BankingDomainTestBase |
|||
{ |
|||
private readonly MoneyTransferManager _transferManager; |
|||
private readonly IRepository<Account, Guid> _accountRepository; |
|||
|
|||
public MoneyTransferManager_IntegrationTests() |
|||
{ |
|||
_transferManager = GetRequiredService<MoneyTransferManager>(); |
|||
_accountRepository = GetRequiredService<IRepository<Account, Guid>>(); |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Transfer_And_Persist_Changes() |
|||
{ |
|||
// Arrange |
|||
var fromAccount = new Account(1000m); |
|||
var toAccount = new Account(500m); |
|||
|
|||
await _accountRepository.InsertAsync(fromAccount); |
|||
await _accountRepository.InsertAsync(toAccount); |
|||
await UnitOfWorkManager.Current.SaveChangesAsync(); |
|||
|
|||
// Act |
|||
await _transferManager.TransferAsync(fromAccount, toAccount, 200m); |
|||
await UnitOfWorkManager.Current.SaveChangesAsync(); |
|||
|
|||
// Assert |
|||
var updatedFrom = await _accountRepository.GetAsync(fromAccount.Id); |
|||
var updatedTo = await _accountRepository.GetAsync(toAccount.Id); |
|||
|
|||
updatedFrom.Balance.ShouldBe(800m); |
|||
updatedTo.Balance.ShouldBe(700m); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
--- |
|||
|
|||
## When NOT to Use a Domain Service |
|||
|
|||
Not every operation needs a domain service. Avoid over-engineering: |
|||
|
|||
1. **Simple CRUD Operations**: Use Application Services directly |
|||
2. **Single Aggregate Operations**: Use Entity methods |
|||
3. **Infrastructure Concerns**: Use Infrastructure Services |
|||
4. **Application Workflow**: Use Application Services |
|||
|
|||
```csharp |
|||
// Don't create a domain service for this ❌ |
|||
public class AccountBalanceReader : DomainService |
|||
{ |
|||
public decimal GetBalance(Account account) => account.Balance; |
|||
} |
|||
|
|||
// Just use the property directly ✅ |
|||
var balance = account.Balance; |
|||
``` |
|||
|
|||
--- |
|||
|
|||
## Summary |
|||
- **Domain Services** are domain-level, not application-level |
|||
- They encapsulate **business logic that doesn't belong to a single entity** |
|||
- They keep your **entities clean** and **business logic consistent** |
|||
- In ABP, inherit from `DomainService` to get built-in features |
|||
- Keep them **focused**, **pure**, and **testable** |
|||
|
|||
--- |
|||
|
|||
## Final Thoughts |
|||
|
|||
Next time you're writing a business rule that doesn't clearly belong to an entity, ask yourself: |
|||
|
|||
> "Is this a Domain Service?" |
|||
|
|||
If it's pure domain logic that coordinates multiple entities or implements a business rule, **put it in the domain layer** - your future self (and your team) will thank you. |
|||
|
|||
Domain Services are a powerful tool in your DDD toolkit. Use them wisely to keep your domain model clean, expressive, and maintainable. |
|||
|
|||
--- |
|||
@ -0,0 +1 @@ |
|||
Learn what Domain Services are in Domain-Driven Design and when to use them in .NET projects. This practical guide covers the difference between Domain and Application Services, features real-world examples including money transfers and order processing, and shows how ABP Framework's DomainService base class simplifies implementation with built-in localization, logging, and event publishing. |
|||
@ -0,0 +1,156 @@ |
|||
# Announcing Server-Side Rendering (SSR) Support for ABP Framework Angular Applications |
|||
|
|||
We are pleased to announce that **Server-Side Rendering (SSR)** has become available for ABP Framework Angular applications! This highly requested feature brings major gains in performance, SEO, and user experience to your Angular applications based on ABP Framework. |
|||
|
|||
## What is Server-Side Rendering (SSR)? |
|||
|
|||
Server-Side Rendering refers to an approach which renders your Angular application on the server as opposed to the browser. The server creates the complete HTML for a page and sends it to the client, which can then show the page to the user. This poses many advantages over traditional client-side rendering. |
|||
|
|||
## Why SSR Matters for ABP Angular Applications |
|||
|
|||
### Improved Performance |
|||
- **Quicker visualization of the first contentful paint (FCP)**: Because prerendered HTML is sent over from the server, users will see content quicker. |
|||
- **Better perceived performance**: Even on slower devices, the page will be displaying something sooner. |
|||
- **Less JavaScript parsing time**: For example, the initial page load will not require parsing and executing a large bundle of JavaScript. |
|||
|
|||
### Enhanced SEO |
|||
- **Improved indexing by search engines**: Search engine bots are able to crawl and index your content quicker. |
|||
- **Improved rankings in search**: The quicker the content loads and the easier it is to access, the better your SEO score. |
|||
- **Preview when sharing on social channels**: Rich previews with the appropriate meta tags are generated when sharing links on social platforms. |
|||
|
|||
### Better User Experience |
|||
- **Support for low bandwidth**: Users with slower Internet connections will have a better experience |
|||
- **Progressive enhancement**: Users can start accessing the content before JavaScript has loaded |
|||
- **Better accessibility**: Screen readers and other assistive technologies can access the content immediately |
|||
|
|||
## Getting Started with SSR |
|||
|
|||
### Adding SSR to an Existing Project |
|||
|
|||
You can easily add SSR support to your existing ABP Angular application using the Angular CLI with ABP schematics: |
|||
|
|||
> Adds SSR configuration to your project |
|||
```bash |
|||
ng generate @abp/ng.schematics:ssr-add |
|||
``` |
|||
> Short form |
|||
```bash |
|||
ng g @abp/ng.schematics:ssr-add |
|||
``` |
|||
If you have multiple projects in your workspace, you can specify which project to add SSR to: |
|||
|
|||
```bash |
|||
ng g @abp/ng.schematics:ssr-add --project=my-project |
|||
``` |
|||
|
|||
If you want to skip the automatic installation of dependencies: |
|||
|
|||
```bash |
|||
ng g @abp/ng.schematics:ssr-add --skip-install |
|||
``` |
|||
|
|||
## What Gets Configured |
|||
|
|||
When you add SSR to your ABP Angular project, the schematic automatically: |
|||
|
|||
1. **Installs necessary dependencies**: Adds `@angular/ssr` and related packages |
|||
2. **Creates Server Configuration**: Creates `server.ts` and related files |
|||
3. **Updates Project Structure**: |
|||
- Creates `main.server.ts` to bootstrap the server |
|||
- Adds `app.config.server.ts` for standalone apps (or `app.module.server.ts` for NgModule apps) |
|||
- Configures server routes in `app.routes.server.ts` |
|||
4. **Updates Build Configuration**: updates `angular.json` to include: |
|||
- a `serve-ssr` target for local SSR development |
|||
- a `prerender` target for static site generation |
|||
- Proper output paths for browser and server bundles |
|||
|
|||
## Supported Configurations |
|||
|
|||
The ABP SSR schematic supports both modern and legacy Angular build configurations: |
|||
|
|||
### Application Builder (Suggested) |
|||
- The new `@angular-devkit/build-angular:application` builder |
|||
- Optimized for Angular 17+ apps |
|||
- Enhanced performance and smaller bundle sizes |
|||
|
|||
### Server Builder (Legacy) |
|||
- The original `@angular-devkit/build-angular:server` builder |
|||
- Designed for legacy Angular applications |
|||
- Compatible with legacy applications |
|||
|
|||
## Running Your SSR Application |
|||
|
|||
After adding SSR to your project, you can run your application in SSR mode: |
|||
|
|||
```bash |
|||
# Development mode with SSR |
|||
ng serve |
|||
|
|||
# Or specifically target SSR development server |
|||
npm run serve:ssr |
|||
|
|||
# Build for production |
|||
npm run build:ssr |
|||
|
|||
# Preview production build |
|||
npm run serve:ssr:production |
|||
``` |
|||
|
|||
## Important Considerations |
|||
|
|||
### Browser-Only APIs |
|||
Some browser APIs are not available on the server. Use platform checks to conditionally execute code: |
|||
|
|||
```typescript |
|||
import { isPlatformBrowser } from '@angular/common'; |
|||
import { PLATFORM_ID, inject } from '@angular/core'; |
|||
|
|||
export class MyComponent { |
|||
private platformId = inject(PLATFORM_ID); |
|||
|
|||
ngOnInit() { |
|||
if (isPlatformBrowser(this.platformId)) { |
|||
// Code that uses browser-only APIs |
|||
console.log('Running in browser'); |
|||
localStorage.setItem('key', 'value'); |
|||
} |
|||
} |
|||
} |
|||
``` |
|||
|
|||
### Storage APIs |
|||
`localStorage` and `sessionStorage` are not accessible on the server. Consider using: |
|||
- Cookies for server-accessible data. |
|||
- The state transfer API for hydration. |
|||
- ABP's built-in storage abstractions. |
|||
|
|||
### Third-Party Libraries |
|||
Please ensure that any third-party libraries you use are compatible with SSR. These libraries can require: |
|||
- Dynamic imports for browser-only code. |
|||
- Platform-specific service providers. |
|||
- Custom Angular Universal integration. |
|||
|
|||
## ABP Framework Integration |
|||
|
|||
The SSR implementation is natively integrated with all of the ABP Framework features: |
|||
|
|||
- **Authentication & Authorization**: The OAuth/OpenID Connect flow functions seamlessly with ABP |
|||
- **Multi-tenancy**: Fully supports tenant resolution and switching |
|||
- **Localization**: Server-side rendering respects the locale |
|||
- **Permission Management**: Permission checks work on both server and client |
|||
- **Configuration**: The ABP configuration system is SSR-ready |
|||
## Performance Tips |
|||
|
|||
1. **Utilize State Transfer**: Send data from server to client to eliminate redundant HTTP requests |
|||
2. **Optimize Images**: Proper image loading strategies, such as lazy loading and responsive images. |
|||
3. **Cache API Responses**: At the server, implement proper caching strategies. |
|||
4. **Monitor Bundle Size**: Keep your server bundle optimized |
|||
5. **Use Prerendering**: The prerender target should be used for static content. |
|||
|
|||
## Conclusion |
|||
|
|||
Server-side rendering can be a very effective feature in improving your ABP Angular application's performance, SEO, and user experience. Our new SSR schematic will make it easier than ever to add SSR to your project. |
|||
|
|||
Try it today and let us know what you think! |
|||
|
|||
--- |
|||
|
After Width: | Height: | Size: 72 KiB |
|
After Width: | Height: | Size: 4.6 KiB |
@ -0,0 +1,354 @@ |
|||
# Building an API Key Management System with ABP Framework |
|||
|
|||
API keys are one of the most common authentication methods for APIs, especially for machine-to-machine communication. In this article, I'll explain what API key authentication is, when to use it, and how to implement a complete API key management system using ABP Framework. |
|||
|
|||
## What is API Key Authentication? |
|||
|
|||
An API key is a unique identifier used to authenticate requests to an API. Unlike user credentials (username/password) or OAuth tokens, API keys are designed for: |
|||
|
|||
- **Programmatic access** - Scripts, CLI tools, and automated processes |
|||
- **Service-to-service communication** - Microservices authenticating with each other |
|||
- **Third-party integrations** - External systems accessing your API |
|||
- **IoT devices** - Embedded systems with limited authentication capabilities |
|||
- **Mobile/Desktop apps** - Native applications that need persistent authentication |
|||
|
|||
## Why Use API Keys? |
|||
|
|||
While modern authentication methods like OAuth2 and JWT are excellent for user authentication, API keys offer distinct advantages in certain scenarios: |
|||
|
|||
**Simplicity**: No complex OAuth flows or token refresh mechanisms. Just include the key in your request header. |
|||
|
|||
**Long-lived**: Unlike JWT tokens that expire in minutes/hours, API keys can remain valid for months or years, making them ideal for automated systems. |
|||
|
|||
**Revocable**: You can instantly revoke a compromised key without affecting user credentials. |
|||
|
|||
**Granular Control**: Different keys for different purposes (read-only, admin, specific services). |
|||
|
|||
## Real-World Use Cases |
|||
|
|||
Here are some practical scenarios where API key authentication shines: |
|||
|
|||
### 1. Mobile Applications |
|||
Your mobile app needs to call your backend APIs. Instead of storing user credentials or managing token refresh flows, use an API key. |
|||
|
|||
```csharp |
|||
// Mobile app configuration |
|||
var apiClient = new ApiClient("https://api.yourapp.com"); |
|||
apiClient.SetApiKey("sk_mobile_prod_abc123..."); |
|||
``` |
|||
|
|||
### 2. Microservice Communication |
|||
Service A needs to call Service B's protected endpoints. |
|||
|
|||
```csharp |
|||
// Order Service calling Inventory Service |
|||
var request = new HttpRequestMessage(HttpMethod.Get, "https://inventory-service/api/products"); |
|||
request.Headers.Add("X-Api-Key", _configuration["InventoryService:ApiKey"]); |
|||
``` |
|||
|
|||
### 3. Third-Party Integrations |
|||
You're providing APIs to external partners or customers. |
|||
|
|||
```bash |
|||
# Customer's integration script |
|||
curl -H "X-Api-Key: pk_partner_xyz789..." \ |
|||
https://api.yourplatform.com/api/orders |
|||
``` |
|||
|
|||
## Implementing API Key Management in ABP Framework |
|||
|
|||
Now let's see how to build a complete API key management system using ABP Framework. I've created an open-source implementation that you can use in your projects. |
|||
|
|||
### Project Overview |
|||
|
|||
The implementation consists of: |
|||
|
|||
- **User-based API keys** - Each key belongs to a specific user |
|||
- **Permission delegation** - Keys inherit user permissions with optional restrictions |
|||
- **Secure storage** - Keys are hashed with SHA-256 |
|||
- **Prefix-based lookup** - Fast key resolution with caching |
|||
- **Web UI** - Manage keys through a user-friendly interface |
|||
- **Multi-tenancy support** - Full ABP multi-tenancy compatibility |
|||
|
|||
 |
|||
|
|||
### Architecture Overview |
|||
|
|||
The solution follows ABP's modular architecture with four main layers: |
|||
|
|||
``` |
|||
┌─────────────────────────────────────────────┐ |
|||
│ Web Layer (UI) │ |
|||
│ • Razor Pages for CRUD operations │ |
|||
│ • JavaScript for client interactions │ |
|||
└─────────────────────────────────────────────┘ |
|||
↓ |
|||
┌─────────────────────────────────────────────┐ |
|||
│ AspNetCore Layer (Middleware) │ |
|||
│ • Authentication Handler │ |
|||
│ • API Key Resolver (Header/Query) │ |
|||
└─────────────────────────────────────────────┘ |
|||
↓ |
|||
┌─────────────────────────────────────────────┐ |
|||
│ Application Layer (Business Logic) │ |
|||
│ • ApiKeyAppService (CRUD operations) │ |
|||
│ • DTO mappings and validations │ |
|||
└─────────────────────────────────────────────┘ |
|||
↓ |
|||
┌─────────────────────────────────────────────┐ |
|||
│ Domain Layer (Core Business) │ |
|||
│ • ApiKey Entity & Manager │ |
|||
│ • IApiKeyRepository │ |
|||
│ • Domain services & events │ |
|||
└─────────────────────────────────────────────┘ |
|||
``` |
|||
|
|||
### Key Components |
|||
|
|||
#### 1. Domain Layer - The Core Entity |
|||
|
|||
```csharp |
|||
public class ApiKey : FullAuditedAggregateRoot<Guid>, IMultiTenant |
|||
{ |
|||
public virtual Guid? TenantId { get; protected set; } |
|||
public virtual Guid UserId { get; protected set; } |
|||
public virtual string Name { get; protected set; } |
|||
public virtual string Prefix { get; protected set; } |
|||
public virtual string KeyHash { get; protected set; } |
|||
public virtual DateTime? ExpiresAt { get; protected set; } |
|||
public virtual bool IsActive { get; protected set; } |
|||
|
|||
// Key format: {prefix}_{key} |
|||
// Only the hash is stored, never the actual key |
|||
} |
|||
``` |
|||
|
|||
**Key Design Decisions:** |
|||
|
|||
- **Prefix-based lookup**: Keys have format `prefix_actualkey`. The prefix is indexed for fast database lookups. |
|||
- **SHA-256 hashing**: The actual key is hashed and never stored in plain text. |
|||
- **User association**: Each key belongs to a user, inheriting their permissions. |
|||
- **Soft delete**: Deleted keys are marked as deleted but not removed from database for audit purposes. |
|||
|
|||
#### 2. Authentication Flow |
|||
|
|||
Here's how authentication works when a request arrives: |
|||
|
|||
 |
|||
|
|||
```csharp |
|||
// 1. Extract API key from request |
|||
var apiKey = httpContext.Request.Headers["X-Api-Key"].FirstOrDefault(); |
|||
if (string.IsNullOrEmpty(apiKey)) return AuthenticateResult.NoResult(); |
|||
|
|||
// 2. Split prefix and key |
|||
var parts = apiKey.Split('_', 2); |
|||
var prefix = parts[0]; |
|||
var key = parts[1]; |
|||
|
|||
// 3. Find key by prefix (cached) |
|||
var apiKeyEntity = await _apiKeyRepository.FindByPrefixAsync(prefix); |
|||
if (apiKeyEntity == null) return AuthenticateResult.Fail("Invalid API key"); |
|||
|
|||
// 4. Verify hash |
|||
var keyHash = HashHelper.ComputeSha256(key); |
|||
if (apiKeyEntity.KeyHash != keyHash) |
|||
return AuthenticateResult.Fail("Invalid API key"); |
|||
|
|||
// 5. Check expiration and active status |
|||
if (apiKeyEntity.ExpiresAt < DateTime.UtcNow || !apiKeyEntity.IsActive) |
|||
return AuthenticateResult.Fail("API key expired or inactive"); |
|||
|
|||
// 6. Create claims principal with user identity |
|||
var claims = new List<Claim> |
|||
{ |
|||
new Claim(AbpClaimTypes.UserId, apiKeyEntity.UserId.ToString()), |
|||
new Claim(AbpClaimTypes.TenantId, apiKeyEntity.TenantId?.ToString() ?? ""), |
|||
new Claim("ApiKeyId", apiKeyEntity.Id.ToString()) |
|||
}; |
|||
|
|||
return AuthenticateResult.Success(ticket); |
|||
``` |
|||
|
|||
#### 3. Creating and Managing API Keys |
|||
|
|||
**Creating a new key:** |
|||
|
|||
 |
|||
|
|||
```csharp |
|||
public class ApiKeyManager : DomainService |
|||
{ |
|||
public async Task<(ApiKey, string)> CreateAsync( |
|||
Guid userId, |
|||
string name, |
|||
DateTime? expiresAt = null) |
|||
{ |
|||
// Generate unique prefix |
|||
var prefix = await GenerateUniquePrefixAsync(); |
|||
|
|||
// Generate secure random key |
|||
var key = GenerateSecureRandomString(32); |
|||
|
|||
// Hash the key for storage |
|||
var keyHash = HashHelper.ComputeSha256(key); |
|||
|
|||
var apiKey = new ApiKey( |
|||
GuidGenerator.Create(), |
|||
userId, |
|||
name, |
|||
prefix, |
|||
keyHash, |
|||
expiresAt, |
|||
CurrentTenant.Id |
|||
); |
|||
|
|||
await _apiKeyRepository.InsertAsync(apiKey); |
|||
|
|||
// Return both entity and the full key (prefix_key) |
|||
// This is the ONLY time the actual key is visible |
|||
return (apiKey, $"{prefix}_{key}"); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
**Important**: The actual key is returned only once during creation. After that, only the hash is stored. |
|||
|
|||
 |
|||
|
|||
### Using API Keys in Your Application |
|||
|
|||
Once created, clients can use the API key to authenticate: |
|||
|
|||
**HTTP Header (Recommended):** |
|||
```bash |
|||
curl -H "X-Api-Key: sk_prod_abc123def456..." \ |
|||
https://api.example.com/api/products |
|||
``` |
|||
|
|||
**JavaScript:** |
|||
```javascript |
|||
const response = await fetch('https://api.example.com/api/products', { |
|||
headers: { |
|||
'X-Api-Key': 'sk_prod_abc123def456...' |
|||
} |
|||
}); |
|||
``` |
|||
|
|||
**C# HttpClient:** |
|||
```csharp |
|||
var client = new HttpClient(); |
|||
client.DefaultRequestHeaders.Add("X-Api-Key", "sk_prod_abc123def456..."); |
|||
var response = await client.GetAsync("https://api.example.com/api/products"); |
|||
``` |
|||
|
|||
**Python:** |
|||
```python |
|||
import requests |
|||
|
|||
headers = {'X-Api-Key': 'sk_prod_abc123def456...'} |
|||
response = requests.get('https://api.example.com/api/products', headers=headers) |
|||
``` |
|||
|
|||
### Permission Management |
|||
|
|||
API keys inherit the user's permissions, but you can further restrict them: |
|||
|
|||
 |
|||
|
|||
This allows scenarios like: |
|||
- Read-only API key for reporting tools |
|||
- Limited scope keys for third-party integrations |
|||
- Service-specific keys with minimal permissions |
|||
|
|||
```csharp |
|||
// Check if current request is authenticated via API key |
|||
if (CurrentUser.FindClaim("ApiKeyId") != null) |
|||
{ |
|||
var apiKeyId = CurrentUser.FindClaim("ApiKeyId").Value; |
|||
// Additional API key specific logic |
|||
} |
|||
``` |
|||
|
|||
## Performance Considerations |
|||
|
|||
The implementation uses several optimizations: |
|||
|
|||
**1. Prefix-based indexing**: Database lookups are done by prefix (indexed column), not the full key hash. |
|||
|
|||
**2. Distributed caching**: API keys are cached after first lookup, dramatically reducing database queries. |
|||
|
|||
```csharp |
|||
// Cache configuration |
|||
Configure<AbpDistributedCacheOptions>(options => |
|||
{ |
|||
options.KeyPrefix = "ApiKey:"; |
|||
}); |
|||
``` |
|||
|
|||
**3. Cache invalidation**: When a key is modified or deleted, cache is automatically invalidated. |
|||
|
|||
**Typical Performance:** |
|||
- Cached lookup: **< 5ms** |
|||
- Database lookup: **< 50ms** |
|||
- Cache hit rate: **~95%** |
|||
|
|||
## Security Best Practices |
|||
|
|||
When implementing API key authentication, follow these guidelines: |
|||
|
|||
✅ **Always use HTTPS** - Never send API keys over unencrypted connections |
|||
|
|||
✅ **Use different keys per environment** - Separate keys for dev, staging, production |
|||
|
|||
❌ **Don't log the full key** - Only log the prefix for debugging |
|||
|
|||
## Getting Started |
|||
|
|||
The complete source code is available on GitHub: |
|||
|
|||
**Repository**: [github.com/salihozkara/AbpApikeyManagement](https://github.com/salihozkara/AbpApikeyManagement) |
|||
|
|||
To integrate it into your ABP project: |
|||
|
|||
1. Clone or download the repository |
|||
2. Add project references to your solution |
|||
3. Add module dependencies to your modules |
|||
4. Run EF Core migrations to create the database tables |
|||
5. Navigate to `/ApiKeyManagement` to start managing keys |
|||
|
|||
```csharp |
|||
// In your Web module |
|||
[DependsOn(typeof(ApiKeyManagementWebModule))] |
|||
public class YourWebModule : AbpModule |
|||
{ |
|||
// ... |
|||
} |
|||
|
|||
// In your HttpApi.Host module |
|||
[DependsOn(typeof(ApiKeyManagementHttpApiModule))] |
|||
public class YourHttpApiHostModule : AbpModule |
|||
{ |
|||
// ... |
|||
} |
|||
``` |
|||
|
|||
## Conclusion |
|||
|
|||
API key authentication remains a crucial part of modern API security, especially for machine-to-machine communication. While it shouldn't replace user authentication methods like OAuth2 for user-facing applications, it's perfect for: |
|||
|
|||
- Automated scripts and tools |
|||
- Service-to-service communication |
|||
- Third-party integrations |
|||
- Long-lived access without token refresh complexity |
|||
|
|||
The implementation shown here demonstrates how ABP Framework's modular architecture, DDD principles, and built-in features (multi-tenancy, caching, permissions) can be leveraged to build a production-ready API key management system. |
|||
|
|||
The solution is open-source and ready to be integrated into your ABP projects. Feel free to explore the code, suggest improvements, or adapt it to your specific needs. |
|||
|
|||
**Resources:** |
|||
- GitHub Repository: [salihozkara/AbpApikeyManagement](https://github.com/salihozkara/AbpApikeyManagement) |
|||
- ABP Framework: [abp.io](https://abp.io) |
|||
- ABP Documentation: [docs.abp.io](https://abp.io/docs/latest) |
|||
|
|||
Happy coding! 🚀 |
|||
@ -0,0 +1 @@ |
|||
Learn how to implement API key authentication in ABP Framework applications. This comprehensive guide covers what API keys are, when to use them over OAuth2/JWT, real-world use cases for mobile apps and microservices, and a complete implementation with user-based key management, SHA-256 hashing, permission delegation, and built-in UI. |
|||
|
After Width: | Height: | Size: 752 KiB |
@ -0,0 +1,322 @@ |
|||
# Signal-Based Forms in Angular 21: Why You’ll Never Miss Reactive Forms Again |
|||
|
|||
Angular 21 introduces one of the most exciting developments in the modern edition of Angular: **Signal-Based Forms**. Built directly on the reactive foundation of Angular signals, this new experimental API provides a cleaner, more intuitive, strongly typed, and ergonomic approach for managing form state—without the heavy boilerplate of Reactive Forms. |
|||
|
|||
> ⚠️ **Important:** Signal Forms are *experimental*. |
|||
> Their API can change. Avoid using them in critical production scenarios unless you understand the risks. |
|||
|
|||
Despite this, Signal Forms clearly represent Angular’s future direction. |
|||
--- |
|||
|
|||
## Why Signal Forms? |
|||
|
|||
Traditionally in Angular, building forms has involved several concerns: |
|||
|
|||
- Tracking values |
|||
- Managing UI interaction states (touched, dirty) |
|||
- Handling validation |
|||
- Keeping UI and model in sync |
|||
|
|||
Reactive Forms solved many challenges but introduced their own: |
|||
|
|||
- Verbosity FormBuilder API |
|||
- Required subscriptions (valueChanges) |
|||
- Manual cleaning |
|||
- Difficult nested forms |
|||
- Weak type-safety |
|||
|
|||
**Signal Forms solve these problems through:** |
|||
|
|||
1." Automatic synchronization |
|||
2." Full type safety |
|||
3." Schema-based validation |
|||
4." Fine-grained reactivity |
|||
5." Drastically reduced boilerplate |
|||
6." Natural integration with Angular Signals |
|||
|
|||
--- |
|||
|
|||
### 1. Form Models — The Core of Signal Forms |
|||
|
|||
A **form model** is simply a writable signal holding the structure of your form data. |
|||
|
|||
```ts |
|||
import { Component, signal } from '@angular/core'; |
|||
import { form, Field } from '@angular/forms/signals'; |
|||
|
|||
@Component({ |
|||
selector: 'app-login', |
|||
imports: [Field], |
|||
template: ` |
|||
<input type="email" [field]="loginForm.email" /> |
|||
<input type="password" [field]="loginForm.password" /> |
|||
`, |
|||
}) |
|||
export class LoginComponent { |
|||
loginModel = signal({ |
|||
email: '', |
|||
password: '', |
|||
}); |
|||
|
|||
loginForm = form(this.loginModel); |
|||
} |
|||
``` |
|||
|
|||
Calling `form(model)` creates a **Field Tree** that maps directly to your model. |
|||
|
|||
--- |
|||
|
|||
### 2. Achieving Full Type Safety |
|||
|
|||
Although TypeScript can infer types from object literals, defining explicit interfaces provides maximum safety and better IDE support. |
|||
|
|||
```ts |
|||
interface LoginData { |
|||
email: string; |
|||
password: string; |
|||
} |
|||
|
|||
loginModel = signal<LoginData>({ |
|||
email: '', |
|||
password: '', |
|||
}); |
|||
|
|||
loginForm = form(loginModel); |
|||
``` |
|||
|
|||
Now: |
|||
|
|||
- `loginForm.email` → `FieldTree<string>` |
|||
- Accessing invalid fields like `loginForm.username` results in compile-time errors |
|||
|
|||
This level of type safety surpasses Reactive Forms. |
|||
|
|||
--- |
|||
|
|||
### 3. Reading Form Values |
|||
|
|||
#### Read from the model (entire form): |
|||
|
|||
```ts |
|||
onSubmit() { |
|||
const data = this.loginModel(); |
|||
console.log(data.email, data.password); |
|||
} |
|||
``` |
|||
|
|||
#### Read from an individual field: |
|||
|
|||
```html |
|||
<p>Current email: {{ loginForm.email().value() }}</p> |
|||
``` |
|||
|
|||
Each field exposes: |
|||
|
|||
- `value()` |
|||
- `valid()` |
|||
- `errors()` |
|||
- `dirty()` |
|||
- `touched()` |
|||
|
|||
All as signals. |
|||
|
|||
--- |
|||
|
|||
### 4. Updating Form Models Programmatically |
|||
|
|||
Signal Forms allow three update methods. |
|||
|
|||
#### 1. Replace the entire model |
|||
|
|||
```ts |
|||
this.userModel.set({ |
|||
name: 'Alice', |
|||
email: 'alice@example.com', |
|||
}); |
|||
``` |
|||
|
|||
#### 2. Patch specific fields |
|||
|
|||
```ts |
|||
this.userModel.update(prev => ({ |
|||
...prev, |
|||
email: newEmail, |
|||
})); |
|||
``` |
|||
|
|||
#### 3. Update a single field |
|||
|
|||
```ts |
|||
this.userForm.email().value.set(''); |
|||
``` |
|||
|
|||
This eliminates the need for: |
|||
|
|||
- `patchValue()` |
|||
- `setValue()` |
|||
- `formGroup.get('field')` |
|||
|
|||
--- |
|||
|
|||
### 5. Automatic Two-Way Binding With `[field]` |
|||
|
|||
The `[field]` directive enables perfect two-way data binding: |
|||
|
|||
```html |
|||
<input [field]="userForm.name" /> |
|||
``` |
|||
|
|||
#### How it works: |
|||
|
|||
- **User input → Field state → Model** |
|||
- **Model updates → Field state → Input UI** |
|||
|
|||
No subscriptions. |
|||
No event handlers. |
|||
No boilerplate. |
|||
|
|||
Reactive Forms could never achieve this cleanly. |
|||
|
|||
--- |
|||
|
|||
### 6. Nested Models and Arrays |
|||
|
|||
Models can contain nested object structures: |
|||
|
|||
```ts |
|||
userModel = signal({ |
|||
name: '', |
|||
address: { |
|||
street: '', |
|||
city: '', |
|||
}, |
|||
}); |
|||
``` |
|||
|
|||
Access fields easily: |
|||
|
|||
```html |
|||
<input [field]="userForm.address.street" /> |
|||
``` |
|||
|
|||
Arrays are also supported: |
|||
|
|||
```ts |
|||
orderModel = signal({ |
|||
items: [ |
|||
{ product: '', quantity: 1, price: 0 } |
|||
] |
|||
}); |
|||
``` |
|||
|
|||
Field state persists even when array items move, thanks to identity tracking. |
|||
|
|||
--- |
|||
|
|||
### 7. Schema-Based Validation |
|||
|
|||
Validation is clean and centralized: |
|||
|
|||
```ts |
|||
import { required, email } from '@angular/forms/signals'; |
|||
|
|||
const model = signal({ email: '' }); |
|||
|
|||
const formRef = form(model, { |
|||
email: [required(), email()], |
|||
}); |
|||
``` |
|||
|
|||
Field validation state is reactive: |
|||
|
|||
```ts |
|||
formRef.email().valid() |
|||
formRef.email().errors() |
|||
formRef.email().touched() |
|||
``` |
|||
|
|||
Validation no longer scatters across components. |
|||
|
|||
--- |
|||
|
|||
### 8. When Should You Use Signal Forms? |
|||
|
|||
#### New Angular 21+ apps |
|||
Signal-first architecture is the new standard. |
|||
|
|||
#### Teams wanting stronger type safety |
|||
Every field is exactly typed. |
|||
|
|||
#### Devs tired of Reactive Form boilerplate |
|||
Signal Forms drastically simplify code. |
|||
|
|||
#### Complex UI with computed reactive form state |
|||
Signals integrate perfectly. |
|||
|
|||
#### ❌ Avoid if: |
|||
- You need long-term stability |
|||
- You rely on mature Reactive Forms features |
|||
- Your app must avoid experimental APIs |
|||
|
|||
--- |
|||
|
|||
### 9. Reactive Forms vs Signal Forms |
|||
|
|||
| Feature | Reactive Forms | Signal Forms | |
|||
|--------|----------------|--------------| |
|||
| Boilerplate | High | Very low | |
|||
| Type-safety | Weak | Strong | |
|||
| Two-way binding | Manual | Automatic | |
|||
| Validation | Scattered | Centralized schema | |
|||
| Nested forms | Verbose | Natural | |
|||
| Subscriptions | Required | None | |
|||
| Change detection | Zone-heavy | Fine-grained | |
|||
|
|||
Signal Forms feel like the "modern Angular mode," while Reactive Forms increasingly feel legacy. |
|||
|
|||
--- |
|||
|
|||
### 10. Full Example: Login Form |
|||
|
|||
```ts |
|||
@Component({ |
|||
selector: 'app-login', |
|||
imports: [Field], |
|||
template: ` |
|||
<form (ngSubmit)="submit()"> |
|||
<input type="email" [field]="form.email" /> |
|||
<input type="password" [field]="form.password" /> |
|||
<button>Login</button> |
|||
</form> |
|||
`, |
|||
}) |
|||
export class LoginComponent { |
|||
model = signal({ email: '', password: '' }); |
|||
form = form(this.model); |
|||
|
|||
submit() { |
|||
console.log(this.model()); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
Minimal. Reactive. Completely type-safe. |
|||
|
|||
--- |
|||
|
|||
## **Conclusion** |
|||
|
|||
Signal Forms in Angular 21 represent a big step forward: |
|||
|
|||
- Cleaner API |
|||
- Stronger type safety |
|||
- Automatic two-way binding |
|||
- Centralized validation |
|||
- Fine-grained reactivity |
|||
- Dramatically better developer experience |
|||
|
|||
|
|||
Although these are experimental, they clearly show the future of Angular's form ecosystem. |
|||
Once you get into using Signal Forms, you may never want to use Reactive Forms again. |
|||
|
|||
--- |
|||
@ -0,0 +1,25 @@ |
|||
**ABP Black Friday Deals are Almost Here\!** |
|||
|
|||
The season of huge savings is back\! We are happy to announce **ABP Black Friday Campaign**, packed with exclusive deals that you simply won't want to miss. Whether you are ready to start building with ABP or looking to expand your existing license, this is your chance to maximize your savings\! |
|||
|
|||
**Campaign Dates: Mark Your Calendar** |
|||
|
|||
Black Friday campaign is live for one week only\! Our deals run from: **November 24th \- December 1st.** |
|||
|
|||
Don't miss this limited-time opportunity to **save up to $3,000** and take your software development to the next level. |
|||
|
|||
**What's Included in the ABP Black Friday Campaign?** |
|||
|
|||
Here’s why this campaign is the best time to buy or upgrade: |
|||
|
|||
* Open to Everyone: This campaign is available for both new and existing customers. |
|||
* Stack Your Savings: You can combine this Black Friday offer with our multi-year discounts for the greatest possible value. |
|||
* Flexible Upgrades: Planning to upgrade to a higher package? Now is the perfect time to make that move at a lower cost. |
|||
* More Developer Seats? No Problem\! Additional developer seats are also eligible under this campaign, allowing you to grow your team effortlessly and affordably. |
|||
|
|||
**Save Money Now\!** |
|||
|
|||
This campaign is your best opportunity all year to unlock advanced features, scale your team, or upgrade your plan while **saving up to $3,000.** Secure your savings before the campaign ends on December 1st\! |
|||
|
|||
[**Visit Pricing Page to Explore Offers\!**](https://abp.io/pricing) |
|||
|
|||
@ -0,0 +1,149 @@ |
|||
# What’s New in .NET 10 Libraries and Runtime? |
|||
|
|||
With .NET 10, Microsoft continues to evolve the platform toward higher performance, stronger security, and modern developer ergonomics. This release brings substantial updates across both the **.NET Libraries** and the **.NET Runtime**, making everyday development faster, safer, and more efficient. |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
## .NET Libraries Improvements |
|||
|
|||
### 1. Post-Quantum Cryptography |
|||
|
|||
.NET 10 introduces support for new **quantum-resistant algorithms**, ML-KEM, ML-DSA, and SLH-DSA, through the `System.Security.Cryptography` namespace. |
|||
These are available when running on compatible OS versions (OpenSSL 3.5+ or Windows CNG). |
|||
|
|||
**Why it matters:** This future-proofs .NET apps against next-generation security threats, keeping them aligned with emerging FIPS standards and PQC readiness. |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
### 2. Numeric Ordering for String Comparison |
|||
|
|||
The `StringComparer` and `HashSet` classes now support **numeric-aware string comparison** via `CompareOptions.NumericOrdering`. |
|||
This allows natural sorting of strings like `v2`, `v10`, `v100`. |
|||
|
|||
**Why it matters:** Cleaner and more intuitive sorting for version names, product codes, and other mixed string-number data. |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
### 3. String Normalization for Spans |
|||
|
|||
Normalization APIs now support `Span<char>` and `ReadOnlySpan<char>`, enabling text normalization without creating new string objects. |
|||
|
|||
**Why it matters:** Lower memory allocations in text-heavy scenarios, perfect for parsers, libraries, and streaming data pipelines. |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
### 4. UTF-8 Support for Hex String Conversion |
|||
|
|||
The `Convert` class now allows **direct UTF-8 to hex conversions**, eliminating the need for intermediate string allocations. |
|||
|
|||
**Why it matters:** Faster serialization and deserialization, especially useful in networking, cryptography, and binary protocols. |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
### 5. Async ZIP APIs |
|||
|
|||
ZIP handling now fully supports asynchronous operations, from creation and extraction to updates, with cancellation support. |
|||
|
|||
**Why it matters:** Ideal for real-time applications, WebSocket I/O, and microservices that handle compressed data streams. |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
### 6. ZipArchive Performance Boost |
|||
|
|||
ZIP operations are now faster and more memory-efficient thanks to parallel extraction and reduced memory pressure. |
|||
|
|||
**Why it matters:** Perfect for file-heavy workloads like installers, packaging tools, and CI/CD utilities. |
|||
|
|||
------ |
|||
|
|||
|
|||
|
|||
### 7. TLS 1.3 Support on macOS |
|||
|
|||
.NET 10 brings **TLS 1.3 client support** to macOS using Apple’s `Network.framework`, integrated with `SslStream` and `HttpClient`. |
|||
|
|||
**Why it matters:** Consistent, faster, and more secure HTTPS connections across Windows, Linux, and macOS. |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
### 8. Telemetry Schema URLs |
|||
|
|||
`ActivitySource` and `Meter` now support **telemetry schema URLs**, aligning with OpenTelemetry standards. |
|||
|
|||
**Why it matters:** Simplifies integration with observability platforms like Grafana, Prometheus, and Application Insights. |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
### 9. OrderedDictionary Performance Improvements |
|||
|
|||
New overloads for `TryAdd` and `TryGetValue` improve performance by returning entry indexes directly. |
|||
|
|||
**Why it matters:** Up to 20% faster JSON updates and more efficient dictionary operations, particularly in `JsonObject`. |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
## .NET Runtime Improvements |
|||
|
|||
|
|||
|
|||
### 1. JIT Compiler Enhancements |
|||
|
|||
- **Faster Struct Handling:** The JIT now passes structs directly via CPU registers, reducing memory operations. |
|||
*→ Result: Faster execution and tighter loops.* |
|||
|
|||
- **Array Interface Devirtualization:** Loops like `foreach` over arrays are now almost as fast as `for` loops. |
|||
*→ Result: Fewer abstraction costs and better inlining.* |
|||
|
|||
- **Improved Code Layout:** A new 3-opt heuristic arranges “hot” code paths closer in memory. |
|||
*→ Result: Better branch prediction and CPU cache performance.* |
|||
|
|||
- **Smarter Inlining:** The JIT can now inline more method types (even with `try-finally`), guided by runtime profiling. |
|||
*→ Result: Reduced overhead for frequently called methods.* |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
### 2. Stack Allocation Improvements |
|||
|
|||
.NET 10 extends stack allocation to **small arrays of both value and reference types**, with **escape analysis** ensuring safe allocation. |
|||
|
|||
**Why it matters:** Fewer heap allocations mean less GC work and faster execution, especially in high-frequency or temporary operations. |
|||
|
|||
|
|||
|
|||
------ |
|||
|
|||
### 3. ARM64 Write-Barrier Optimization |
|||
|
|||
The garbage collector’s write-barrier logic is now optimized for ARM64, cutting unnecessary memory scans. |
|||
|
|||
**Why it matters:** Up to **20% shorter GC pauses** and better overall performance on ARM-based devices and servers. |
|||
|
|||
|
|||
|
|||
|
|||
|
|||
## Summary |
|||
|
|||
.NET 10 doubles down on **performance, efficiency, and modern standards**. From quantum-ready cryptography to smarter memory management and diagnostics, this release makes .NET more ready than ever for the next generation of applications. |
|||
|
|||
Whether you’re building enterprise APIs, distributed systems, or cloud-native tools, upgrading to .NET 10 means faster code, safer systems, and better developer experience. |
|||
@ -0,0 +1,158 @@ |
|||
# My First Look and Experience with Google AntiGravity |
|||
|
|||
## Is Google AntiGravity Going to Replace Your Main Code Editor? |
|||
|
|||
Today, I tried the new code-editor AntiGravity by Google. *"It's beyond a code-editor*" by Google 🙄 |
|||
When I first launch it, I see the UI is almost same as Cursor. They're both based on Visual Studio Code. |
|||
That's why it was not hard to find what I'm looking for. |
|||
|
|||
First of all, the main difference as I see from the Cursor is; when I type a prompt in the agent section **AntiGravity first creates a Task List** (like a road-map) and whenever it finishes a task, it checks the corresponding task. Actually Cursor has a similar functionality but AntiGravity took it one step further. |
|||
|
|||
Second thing which was good to me; AntiGravity uses [Nano Banana 🍌](https://gemini.google/tr/overview/image-generation/). This is Google's AI image generation model... Why it's important because when you create an app, you don't need to search for graphics, deal with image licenses. **AntiGravity generates images automatically and no license is required!** |
|||
|
|||
Third exciting feature for me; **AntiGravity is integrated with Google Chrome and can communicate with the running website**. When I first run my web project, it installed a browser extension which can see and interact with my website. It can see the results, click somewhere else on the page, scroll, fill up the forms, amazing 😵 |
|||
|
|||
Another feature I loved is that **you can enter a new prompt even while AntiGravity is still generating a response** 🧐. It instantly prioritizes the latest input and adjusts the ongoing process if needed. But in Cursor, if you add a prompt before the cursor finishes, it simply queues it and runs it later 😔. |
|||
|
|||
And lastly, **AntiGravity is working very good with Gemini 3**. |
|||
|
|||
Well, everything was not so perfect 😥 When I tried AntiGravity, couple of times it stucked AI generation and Agent stopped. I faced errors like this 👇 |
|||
|
|||
 |
|||
|
|||
|
|||
|
|||
## Debugging .NET Projects via AntiGravity |
|||
|
|||
⚠ There's a crucial development issue with AntiGravity (and also for Cursor, Windsurf etc...) 🤕 you **cannot debug your .NET application with AntiGravity 🥺.** *This is Microsoft's policy!* Microsoft doesn't allow debugging for 3rd party IDEs and shows the below error... That's why I cannot say it's a downside of AntiGravity. You need to use Microsft's original VS Code, Visual Studio or Rider for debugging. But wait a while there's a workaround for this, I'll let you know in the next section. |
|||
|
|||
|
|||
|
|||
 |
|||
|
|||
### What does this error mean? |
|||
|
|||
AntiGravity, Cursor, Windsurf etc... are using Visual Studio Code and the C# extension for VS Code includes the Microsoft .NET Core Debugger "*vsdbg*". |
|||
VS Code is open-source but "*vsdbg*" is not open-source! It's working only with Visual Studio Code, Visual Studio and Visual Studio for Mac. This is clearly stated at [Microsoft's this link](https://github.com/dotnet/vscode-csharp/blob/main/docs/debugger/Microsoft-.NET-Core-Debugger-licensing-and-Microsoft-Visual-Studio-Code.md). |
|||
|
|||
### Ok! How to resolve debugging issue with AntiGravity? and Cursor and Windsurf... |
|||
|
|||
There's a free C# debugger extension for Visual Studio Code based IDEs that supports AntiGravity, Cursor and Windsurf. The extension name is **C#**. |
|||
You can download this free C# debugger extension at 👉 [open-vsx.org/extension/muhammad-sammy/csharp/](https://open-vsx.org/extension/muhammad-sammy/csharp/). |
|||
For AntiGravity open Extension window (*Ctrl + Shift + X*) and search for `C#`, there you'll see this extension. |
|||
|
|||
 |
|||
|
|||
After installing, I restarted AntiGravity and now I can see the red circle which allows me to add breakpoint on C# code. |
|||
|
|||
 |
|||
|
|||
### Another Extension For Debugging .NET Apps on VS Code |
|||
|
|||
Recently I heard about DotRush extension from the folks. As they say DotRush works slightly faster and support Razor pages (.cshtml files). |
|||
Here's the link for DotRush https://github.com/JaneySprings/DotRush |
|||
|
|||
### Finding Website Running Port |
|||
|
|||
When you run the web project via C# debugger extension, normally it's not using the `launch.json` therefore the website port is not the one when you start from Visual Studio / Rider... So what's my website's port which I just run now? Normally for ASP.NET Core **the default port is 5000**. You can try navigating to http://localhost:5000/. |
|||
Alternatively you can write the below code in `Program.cs` which prints the full address of your website in the logs. |
|||
If you do the steps which I showed you, you can debug your C# application via AntiGravity and other VS Code derivatives. |
|||
|
|||
 |
|||
|
|||
## How Much is AntiGravity? 💲 |
|||
|
|||
Currently there's only individual plan is available for personal accounts and that's free 👏! The contents of Team and Enterprise plans and prices are not announced yet. But **Gemini 3 is not free**! I used it with my company's Google Workspace account which we normally pay for Gemini. |
|||
|
|||
 |
|||
|
|||
## More About AntiGravity |
|||
|
|||
There have been many AI assisted IDEs like [Windsurf](https://windsurf.com/), [Cursor](https://cursor.com/), [Zed](https://zed.dev/), [Replit](https://replit.com/) and [Fleet](https://www.jetbrains.com/fleet/). But this time it's different, this is backed by Google. |
|||
As you see from the below image AntiGravity, uses a standard grid layout as others based on VS Code editor. |
|||
It's very similar to Cursor, Visual Studio, Rider. |
|||
|
|||
 |
|||
|
|||
## Supported LLMs 🧠 |
|||
|
|||
Antigravity offers the below models which supports reasoning: Gemini 3 Pro, Claude Sonnet 4.5, GPT-OSS |
|||
|
|||
 |
|||
|
|||
Antigravity uses other models for supportive tasks in the background: |
|||
|
|||
- **Nano banana**: This is used to generate images. |
|||
- **Gemini 2.5 Pro UI Checkpoint**: It's for the browser subagent to trigger browser action such as clicking, scrolling, or filling in input. |
|||
- **Gemini 2.5 Flash**: For checkpointing and context summarization, this is used. |
|||
- **Gemini 2.5 Flash Lite**: And when it's need to make a semantic search in your code-base, this is used. |
|||
|
|||
## AntiGravity Can See Your Website |
|||
|
|||
This makes a big difference from traditional IDEs. AntiGravity's browser agent is taking screenshots of your pages when it needs to check. This is achieved by a Chrome Extension as a tool to the agent, and you can also prompt the agent to take a screenshot of a page. It can iterate on website designs and implementations, it can perform UI Testing, it can monitor dashboards, it can automate routine tasks like rerunning CI. |
|||
This is the link for the extension 👉 [chromewebstore.google.com/detail/antigravity-browser-exten/eeijfnjmjelapkebgockoeaadonbchdd](https://chromewebstore.google.com/detail/antigravity-browser-exten/eeijfnjmjelapkebgockoeaadonbchdd). AntiGravity will install this extension automatically on the first run. |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
## MCP Integration |
|||
|
|||
### When Do We Need MCP in a Code Editor? |
|||
|
|||
Simply if we want to connect to a 3rd party service to complete our task we need MCP. So AntiGravity can connect to your DB and write proper SQL queries or it can pull in recent build logs from Netlify or Heroku. Also you can ask AntiGravity to to connect GitHub for finding the best authentication pattern. |
|||
|
|||
### AntiGravity Supports These MCP Servers |
|||
|
|||
Airweave, AlloyDB for PostgreSQL, Atlassian, BigQuery, Cloud SQL for PostgreSQL, Cloud SQL for MySQL, Cloud SQL for SQL Server, Dart, Dataplex, Figma Dev Mode MCP, Firebase, GitHub, Harness, Heroku, Linear, Locofy, Looker, MCP Toolbox for Databases, MongoDB, Neon, Netlify, Notion, PayPal, Perplexity Ask, Pinecone, Prisma, Redis, Sequential Thinking, SonarQube, Spanner, Stripe and Supabase. |
|||
|
|||
 |
|||
|
|||
## Agent Settings ⚙️ |
|||
|
|||
The major settings of Agent are: |
|||
|
|||
- **Agent Auto Fix Lints**: I enabled this setting because I want the Agent automatically fixes its own mistakes for invalid syntax, bad formatting, unused variables, unreachable code or following coding standards... It makes extra tool calls that's why little bit expensive 🥴. |
|||
- **Auto Execution**: Sometimes Agent tries to build application or writing test code and running it, in these cases it executes command. I choose "Turbo" 🤜 With this option, Agent always runs the terminal command and controls my browser. |
|||
- **Review Policy**: How much control you are giving to agent 🙎. I choose "Always Proceed" 👌 because I mostly trust AI 😀. The Agent will never ask for review. |
|||
|
|||
 |
|||
|
|||
## Differences Between Cursor and AntiGravity |
|||
|
|||
While Cursor was the champion of AI code editors, **Antigravity brings a different philosophy**. |
|||
|
|||
### 1. "Agent-First 🤖" vs "You-First 🤠" |
|||
|
|||
- **Cursor:** It acts like an assistant; it predicts your next move, auto-completes your thoughts, and helps you refactor while you type. You are still the driver; Cursor just drives the car at 200 km/h. |
|||
- **Antigravity:** Antigravity is built to let you manage coding tasks. It is "Agent-First." You don't just type code; you assign tasks to autonomous agents (e.g., "Fix the bug in the login flow and verify it in the browser"). It behaves more like a junior developer that you supervise. |
|||
|
|||
### 2. The Interface |
|||
|
|||
- **Cursor:** Looks and feels exactly like **VS Code**. If you know VS Code, you know Cursor. |
|||
|
|||
- **Antigravity:** Introduces 2 major layouts: |
|||
- **Editor View:** Similar to a standard IDE |
|||
- **Manager View:** A dashboard where you see multiple "Agents" working in parallel. You can watch them plan, execute, and test tasks asynchronously. |
|||
|
|||
### 3. Verification & Trust |
|||
|
|||
- **Cursor:** You verify by reading the code diffs it suggests. |
|||
- **Antigravity:** Introduces **Artifacts**... Since the agents work autonomously, they generate proof-of-work documents, screenshots of the app running, browser logs and execution plans. So you can verify what they did without necessarily reading every line of code immediately. |
|||
|
|||
### 4. Capabilities |
|||
|
|||
- **Cursor:** Best-in-class **Autocomplete** ("Tab" feature) and **Composer** (multi-file editing). It excels at "Vibe Coding". It's getting into a flow state where the AI writes the boilerplate and you direct the logic. |
|||
- **Antigravity:** Is good at **Autonomous Execution**. It has a built-in browser and terminal that the *Agent* controls. The Agent can write code, run the server, open the browser, see the error, and fix it 😎 |
|||
|
|||
### 5. AI Models (Brains 🧠) |
|||
|
|||
- **Cursor:** Model Agnostic. You can switch between **Claude 3.5 Sonnet** *-mostly the community uses this-*, GPT-4o, and others. |
|||
- **Antigravity:** Built deeply around **Gemini 3 Pro**. It leverages Gemini's massive context window (1M+ tokens) to understand huge mono repos without needing as much "RAG" as Cursor. |
|||
|
|||
|
|||
|
|||
## Try It Yourself Now 🤝 |
|||
|
|||
If you are ready to experience the new AI code editor by Google, download and use 👇 |
|||
[**Launch Google AntiGravity**](https://antigravity.google/) |
|||
|
After Width: | Height: | Size: 70 KiB |
|
After Width: | Height: | Size: 183 KiB |
|
After Width: | Height: | Size: 62 KiB |
|
After Width: | Height: | Size: 1.1 MiB |
|
After Width: | Height: | Size: 90 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 102 KiB |
|
After Width: | Height: | Size: 293 KiB |
|
After Width: | Height: | Size: 76 KiB |
|
After Width: | Height: | Size: 46 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 275 KiB |
|
After Width: | Height: | Size: 49 KiB |
|
After Width: | Height: | Size: 154 KiB |
|
After Width: | Height: | Size: 5.4 KiB |
|
After Width: | Height: | Size: 6.3 KiB |
|
After Width: | Height: | Size: 6.0 KiB |
|
After Width: | Height: | Size: 4.8 KiB |
|
After Width: | Height: | Size: 7.2 KiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 6.6 KiB |
@ -0,0 +1,414 @@ |
|||
# Building Production-Ready LLM Applications with .NET: A Practical Guide |
|||
|
|||
Large Language Models (LLMs) have evolved rapidly, and integrating them into production .NET applications requires staying current with the latest approaches. In this article, I'll share practical tips and patterns I've learned while building LLM-powered systems, covering everything from API changes in GPT-5 to implementing efficient RAG (Retrieval Augmented Generation) architectures. |
|||
|
|||
Whether you're building a chatbot, a knowledge base assistant, or integrating AI into your enterprise applications, these production-tested insights will help you avoid common pitfalls and build more reliable systems. |
|||
|
|||
## The Temperature Paradigm Shift: GPT-5 Changes Everything |
|||
|
|||
If you've been working with GPT-4 or earlier models, you're familiar with the `temperature` and `top_p` parameters for controlling response randomness. **Here's the critical update**: GPT-5 no longer supports these parameters! |
|||
|
|||
### The Old Way (GPT-4) |
|||
```csharp |
|||
var chatRequest = new ChatOptions |
|||
{ |
|||
Temperature = 0.7, // ✅ Worked with GPT-4 |
|||
TopP = 0.9 // ✅ Worked with GPT-4 |
|||
}; |
|||
``` |
|||
|
|||
### The New Way (GPT-5) |
|||
```csharp |
|||
var chatRequest = new ChatOptions |
|||
{ |
|||
RawRepresentationFactory = (client => new ChatCompletionOptions() |
|||
{ |
|||
#pragma warning disable OPENAI001 |
|||
ReasoningEffortLevel = "minimal", |
|||
#pragma warning restore OPENAI001 |
|||
}) |
|||
}; |
|||
``` |
|||
|
|||
**Why the change?** GPT-5 incorporates an internal reasoning and verification process. Instead of controlling randomness, you now specify how much computational effort the model should invest in reasoning through the problem. |
|||
|
|||
 |
|||
|
|||
### Choosing the Right Reasoning Level |
|||
|
|||
- **Low**: Quick responses for simple queries (e.g., "What's the capital of France?") |
|||
- **Medium**: Balanced approach for most use cases |
|||
- **High**: Complex reasoning tasks (e.g., code generation, multi-step problem solving) |
|||
|
|||
> **Pro Tip**: Reasoning tokens are included in your API costs. Use "High" only when necessary to optimize your budget. |
|||
|
|||
## System Prompts: The "Lost in the Middle" Problem |
|||
|
|||
Here's a critical insight that can save you hours of debugging: **Important rules must be repeated at the END of your prompt!** |
|||
|
|||
### ❌ What Doesn't Work |
|||
``` |
|||
You are a helpful assistant. |
|||
RULE: Never share passwords or sensitive information. |
|||
|
|||
[User Input] |
|||
``` |
|||
|
|||
### ✅ What Actually Works |
|||
``` |
|||
You are a helpful assistant. |
|||
RULE: Never share passwords or sensitive information. |
|||
|
|||
[User Input] |
|||
|
|||
⚠️ REMINDER: Apply the rules above strictly, ESPECIALLY regarding passwords. |
|||
``` |
|||
|
|||
**Why?** LLMs suffer from the "Lost in the Middle" phenomenon—they pay more attention to the beginning and end of the context window. Critical instructions buried in the middle are often ignored. |
|||
|
|||
## RAG Architecture: The Parent-Child Pattern |
|||
|
|||
Retrieval Augmented Generation (RAG) is essential for grounding LLM responses in your own data. The most effective pattern I've found is the **Parent-Child approach**. |
|||
|
|||
 |
|||
|
|||
### How It Works |
|||
|
|||
1. **Split documents into hierarchies**: |
|||
- **Parent chunks**: Large sections (1000-2000 tokens) for context |
|||
- **Child chunks**: Small segments (200-500 tokens) for precise retrieval |
|||
|
|||
2. **Store both in vector database** with references |
|||
|
|||
3. **Query flow**: |
|||
- Search using child chunks (higher precision) |
|||
- Return parent chunks to LLM (richer context) |
|||
|
|||
### The Overlap Strategy |
|||
|
|||
Always use overlapping chunks to prevent information loss at boundaries! |
|||
|
|||
``` |
|||
Chunk 1: Token 0-500 |
|||
Chunk 2: Token 400-900 ← 100 token overlap |
|||
Chunk 3: Token 800-1300 ← 100 token overlap |
|||
``` |
|||
|
|||
**Standard recommendation**: 10-20% overlap (for 500 tokens, use 50-100 token overlap) |
|||
|
|||
### Implementation with Semantic Kernel |
|||
|
|||
```csharp |
|||
using Microsoft.SemanticKernel.Text; |
|||
|
|||
var chunks = TextChunker.SplitPlainTextParagraphs( |
|||
documentText, |
|||
maxTokensPerParagraph: 500, |
|||
overlapTokens: 50 |
|||
); |
|||
|
|||
foreach (var chunk in chunks) |
|||
{ |
|||
var embedding = await embeddingService.GenerateEmbeddingAsync(chunk); |
|||
await vectorDb.StoreAsync(chunk, embedding); |
|||
} |
|||
``` |
|||
|
|||
## PostgreSQL + pgvector: The Pragmatic Choice |
|||
|
|||
For .NET developers, choosing a vector database can be overwhelming. After evaluating multiple options, **PostgreSQL with pgvector** is the most practical choice for most scenarios. |
|||
|
|||
 |
|||
|
|||
### Why pgvector? |
|||
|
|||
✅ **Use existing SQL knowledge** - No new query language to learn |
|||
✅ **EF Core integration** - Works with your existing data access layer |
|||
✅ **JOIN with metadata** - Combine vector search with traditional queries |
|||
✅ **WHERE clause filtering** - Filter by tenant, user, date, etc. |
|||
✅ **ACID compliance** - Transaction support for data consistency |
|||
✅ **No separate infrastructure** - One database for everything |
|||
|
|||
### Setting Up pgvector with EF Core |
|||
|
|||
First, install the NuGet package: |
|||
|
|||
```bash |
|||
dotnet add package Pgvector.EntityFrameworkCore |
|||
``` |
|||
|
|||
Define your entity: |
|||
|
|||
```csharp |
|||
using Pgvector; |
|||
using Pgvector.EntityFrameworkCore; |
|||
|
|||
public class DocumentChunk |
|||
{ |
|||
public Guid Id { get; set; } |
|||
public string Content { get; set; } |
|||
public Vector Embedding { get; set; } // 👈 pgvector type |
|||
public Guid ParentChunkId { get; set; } |
|||
public DateTime CreatedAt { get; set; } |
|||
} |
|||
``` |
|||
|
|||
Configure in DbContext: |
|||
|
|||
```csharp |
|||
protected override void OnModelCreating(ModelBuilder builder) |
|||
{ |
|||
builder.HasPostgresExtension("vector"); |
|||
|
|||
builder.Entity<DocumentChunk>() |
|||
.Property(e => e.Embedding) |
|||
.HasColumnType("vector(1536)"); // 👈 OpenAI embedding dimension |
|||
|
|||
builder.Entity<DocumentChunk>() |
|||
.HasIndex(e => e.Embedding) |
|||
.HasMethod("hnsw") // 👈 Fast approximate search |
|||
.HasOperators("vector_cosine_ops"); |
|||
} |
|||
``` |
|||
|
|||
### Performing Vector Search |
|||
|
|||
```csharp |
|||
using Pgvector.EntityFrameworkCore; |
|||
|
|||
public async Task<List<DocumentChunk>> SearchAsync(string query) |
|||
{ |
|||
// 1. Convert query to embedding |
|||
var queryVector = await _embeddingService.GetEmbeddingAsync(query); |
|||
|
|||
// 2. Search |
|||
return await _context.DocumentChunks |
|||
.OrderBy(c => c.Embedding.L2Distance(queryVector)) // 👈 Lower is better |
|||
.Take(5) |
|||
.ToListAsync(); |
|||
} |
|||
``` |
|||
|
|||
**Source**: [Pgvector.NET on GitHub](https://github.com/pgvector/pgvector-dotnet?tab=readme-ov-file#entity-framework-core) |
|||
|
|||
## Smart Tool Usage: Make RAG a Tool, Not a Tax |
|||
|
|||
A common mistake is calling RAG on every single user message. This wastes tokens and money. Instead, **make RAG a tool** and let the LLM decide when to use it. |
|||
|
|||
### ❌ Expensive Approach |
|||
```csharp |
|||
// Always call RAG, even for "Hello" |
|||
var context = await PerformRAG(userMessage); |
|||
var response = await chatClient.CompleteAsync($"{context}\n\n{userMessage}"); |
|||
``` |
|||
|
|||
### ✅ Smart Approach |
|||
```csharp |
|||
[KernelFunction] |
|||
[Description("Search the company knowledge base for information")] |
|||
public async Task<string> SearchKnowledgeBase( |
|||
[Description("The search query")] string query) |
|||
{ |
|||
var results = await _vectorDb.SearchAsync(query); |
|||
return string.Join("\n---\n", results.Select(r => r.Content)); |
|||
} |
|||
``` |
|||
|
|||
The LLM will call `SearchKnowledgeBase` only when needed: |
|||
- "Hello" → No tool call |
|||
- "What was our 2024 revenue?" → Calls tool |
|||
- "Tell me a joke" → No tool call |
|||
|
|||
## Multilingual RAG: Query Translation Strategy |
|||
|
|||
When your documents are in one language (e.g., English) but users query in another (e.g., Turkish), you need a translation strategy. |
|||
|
|||
 |
|||
|
|||
### Solution Options |
|||
|
|||
**Option 1**: Use an LLM that automatically calls tools in English |
|||
- Many modern LLMs can do this if properly instructed |
|||
|
|||
**Option 2**: Tool chain approach |
|||
```csharp |
|||
[KernelFunction] |
|||
[Description("Translate text to English")] |
|||
public async Task<string> TranslateToEnglish(string text) |
|||
{ |
|||
// Translation logic |
|||
} |
|||
|
|||
[KernelFunction] |
|||
[Description("Search knowledge base (English only)")] |
|||
public async Task<string> SearchKnowledgeBase(string englishQuery) |
|||
{ |
|||
// Search logic |
|||
} |
|||
``` |
|||
|
|||
The LLM will: |
|||
1. Call `TranslateToEnglish("2024 geliri nedir?")` |
|||
2. Get "What was 2024 revenue?" |
|||
3. Call `SearchKnowledgeBase("What was 2024 revenue?")` |
|||
4. Return results and respond in Turkish |
|||
|
|||
## Model Context Protocol (MCP): Beyond In-Process Tools |
|||
|
|||
Microsoft and Anthropic recently released official C# SDKs for the Model Context Protocol (MCP). This is a game-changer for tool reusability. |
|||
|
|||
 |
|||
|
|||
### MCP vs. Semantic Kernel Plugins |
|||
|
|||
| Feature | SK Plugins | MCP Servers | |
|||
|---------|-----------|-------------| |
|||
| **Process** | In-process | Out-of-process (stdio/http) | |
|||
| **Reusability** | Application-specific | Cross-application | |
|||
| **Examples** | Used within your app | VS Code Copilot, Claude Desktop | |
|||
|
|||
### Creating an MCP Server |
|||
|
|||
```csharp |
|||
using Microsoft.Extensions.Hosting; |
|||
using ModelContextProtocol.Extensions.Hosting; |
|||
|
|||
var builder = Host.CreateEmptyApplicationBuilder(settings: null); |
|||
|
|||
builder.Services.AddMcpServer() |
|||
.WithStdioServerTransport() |
|||
.WithToolsFromAssembly(); |
|||
|
|||
await builder.Build().RunAsync(); |
|||
``` |
|||
|
|||
Define your tools: |
|||
|
|||
```csharp |
|||
[McpServerToolType] |
|||
public static class FileSystemTools |
|||
{ |
|||
[McpServerTool, Description("Read a file from the file system")] |
|||
public static async Task<string> ReadFile(string path) |
|||
{ |
|||
// ⚠️ SECURITY: Always validate paths! |
|||
if (!IsPathSafe(path)) |
|||
throw new SecurityException("Invalid path"); |
|||
|
|||
return await File.ReadAllTextAsync(path); |
|||
} |
|||
|
|||
private static bool IsPathSafe(string path) |
|||
{ |
|||
// Implement path traversal prevention |
|||
var fullPath = Path.GetFullPath(path); |
|||
return fullPath.StartsWith(AllowedDirectory); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
Your MCP server can now be used by VS Code Copilot, Claude Desktop, or any other MCP client! |
|||
|
|||
## Chat History Management: Truncation + RAG Hybrid |
|||
|
|||
For long conversations, storing all history in the context window becomes impractical. Here's the pattern that works: |
|||
|
|||
 |
|||
|
|||
### ❌ Lossy Approach |
|||
``` |
|||
First 50 messages → Summarize with LLM → Single summary message |
|||
``` |
|||
**Problem**: Detail loss (fidelity loss) |
|||
|
|||
### ✅ Hybrid Approach |
|||
1. **Recent messages** (last 5-10): Keep in prompt for immediate context |
|||
2. **Older messages**: Store in vector database as a tool |
|||
|
|||
```csharp |
|||
[KernelFunction] |
|||
[Description("Search conversation history for past discussions")] |
|||
public async Task<string> SearchChatHistory( |
|||
[Description("What to search for")] string query) |
|||
{ |
|||
var relevantMessages = await _vectorDb.SearchAsync(query); |
|||
return string.Join("\n", relevantMessages.Select(m => |
|||
$"[{m.Timestamp}] {m.Role}: {m.Content}")); |
|||
} |
|||
``` |
|||
|
|||
The LLM retrieves only relevant past context when needed, avoiding summary-induced information loss. |
|||
|
|||
## RAG vs. Fine-Tuning: Choose Wisely |
|||
|
|||
A common misconception is using fine-tuning for knowledge injection. Here's when to use each: |
|||
|
|||
| Purpose | RAG | Fine-Tuning | |
|||
|---------|-----|-------------| |
|||
| **Goal** | Memory (provide facts) | Behavior (teach style) | |
|||
| **Updates** | Dynamic (add docs anytime) | Static (requires retraining) | |
|||
| **Cost** | Low dev, higher inference | High dev, lower inference | |
|||
| **Hallucination** | Reduces | Doesn't reduce | |
|||
| **Use Case** | Company docs, FAQs | Brand voice, specific format | |
|||
|
|||
**Common mistake**: "Let's fine-tune on our company documents" ❌ |
|||
**Better approach**: Use RAG! ✅ |
|||
|
|||
Fine-tuning is for teaching the model *how* to respond, not *what* to know. |
|||
|
|||
**Source**: [Oracle - RAG vs Fine-Tuning](https://www.oracle.com/artificial-intelligence/generative-ai/retrieval-augmented-generation-rag/rag-fine-tuning/) |
|||
|
|||
## Bonus: Why SVG is Superior for LLM-Generated Images |
|||
|
|||
When using LLMs to generate diagrams and visualizations, always request SVG format instead of PNG or JPG. |
|||
|
|||
### Why SVG? |
|||
|
|||
✅ **Text-based** → LLMs produce better results |
|||
✅ **Lower cost** → Fewer tokens than base64-encoded images |
|||
✅ **Editable** → Easy to modify after generation |
|||
✅ **Scalable** → Perfect quality at any size |
|||
✅ **Version control friendly** → Works great in Git |
|||
|
|||
### Example Prompt |
|||
|
|||
``` |
|||
Create an architecture diagram showing PostgreSQL with pgvector integration. |
|||
Format: SVG, 800x400 pixels. Show: .NET Application → EF Core → PostgreSQL → Vector Search. |
|||
Use arrows to connect stages. Color scheme: Blue tones. |
|||
``` |
|||
|
|||
 |
|||
|
|||
All diagrams in this article were generated as SVG, resulting in excellent quality and lower token costs! |
|||
|
|||
> **Pro Tip**: If you don't need photographs or complex renders, always choose SVG. |
|||
|
|||
## Architecture Roadmap: Putting It All Together |
|||
|
|||
Here's the recommended stack for building production LLM applications with .NET: |
|||
|
|||
1. **Orchestration**: Microsoft.Extensions.AI + Semantic Kernel (when needed) |
|||
2. **Vector Database**: PostgreSQL + Pgvector.EntityFrameworkCore |
|||
3. **RAG Pattern**: Parent-Child chunks with 10-20% overlap |
|||
4. **Tools**: MCP servers for reusability |
|||
5. **Reasoning**: ReasoningEffortLevel instead of temperature |
|||
6. **Prompting**: Critical rules at the end |
|||
7. **Cost Optimization**: Make RAG a tool, not automatic |
|||
|
|||
## Key Takeaways |
|||
|
|||
Let me summarize the most important production tips: |
|||
|
|||
1. **Temperature is gone** → Use `ReasoningEffortLevel` with GPT-5 |
|||
2. **Rules at the end** → Combat "Lost in the Middle" |
|||
3. **RAG as a tool** → Reduce costs significantly |
|||
4. **Parent-Child pattern** → Search small, respond with large |
|||
5. **Always use overlap** → 10-20% is the standard |
|||
6. **pgvector for most cases** → Unless you have billions of vectors |
|||
7. **MCP for reusability** → One codebase, works everywhere |
|||
8. **SVG for diagrams** → Better results, lower cost |
|||
9. **Hybrid chat history** → Recent in prompt, old in vector DB |
|||
10. **RAG > Fine-tuning** → For knowledge, not behavior |
|||
|
|||
Happy coding! 🚀 |
|||
@ -0,0 +1 @@ |
|||
Learn how to build production-ready LLM applications with .NET. This comprehensive guide covers GPT-5 API changes, advanced RAG architectures with parent-child patterns, PostgreSQL pgvector integration, smart tool usage strategies, multilingual query handling, Model Context Protocol (MCP) for cross-application tool reusability, and chat history management techniques for enterprise applications. |
|||
@ -0,0 +1,60 @@ |
|||
# .NET Conf China 2025: Changing the World, Changing Ourselves - See You Again in Shanghai |
|||
|
|||
 |
|||
|
|||
.NET Conf China 2025 is an annual community event for developers, celebrating the release of .NET 10 (LTS) and the achievements of the past year in China. As an extension of .NET Conf 2025, this event brings together local tech communities, well-known companies, and open-source organizations. It has become the largest .NET online and offline conference in China, dedicated to spreading .NET technology in Chinese and fostering collaboration and exchange. |
|||
|
|||
## Event Highlights: Key Topics and Takeaways |
|||
|
|||
This year’s conference focused on three main themes: performance improvements, AI integration, and cross-platform development. Topics covered how to achieve performance gains while maintaining engineering quality, balancing between multi-platform consistency and native capabilities, and taking generative AI from “demo-level” to “production-ready.” On the community and ecosystem side, the event showcased the .NET Foundation’s and domestic and international companies’ progress in supporting architectures like ARM, LoongArch, and RISC-V. It also highlighted best practices in DevOps, observability, and engineering toolchains, creating a complete path from ideas to implementation. |
|||
|
|||
### Opening Keynote |
|||
|
|||
Scott Hanselman kicked off .NET Conf China 2025 with a video keynote, announcing that .NET 10 is now available on the official website. He framed the release around four pillars—AI, cloud-native, cross-platform, and performance—including integration with the Microsoft Agent Framework for building and orchestrating multi-agent systems in .NET/C#, industry-leading container and Kubernetes support with .NET Aspire simplifying local containerized development, a richer cross-platform desktop ecosystem (.NET MAUI, Avalonia, Uno Platform), and major performance gains such as Native AOT and single-file publishing for faster startup and easier distribution across platforms. |
|||
|
|||
He underscored China’s importance as .NET’s second-largest market, with roughly 13% of users, and noted that generative AI usage in China has doubled in 2025. The local community is seeing strong momentum around ML.NET, .NET Aspire, and the C# Dev Kit in VS Code. Reflecting on his Baby Smash game written 20 years ago, which now runs cross-platform on .NET 10, he called on developers to modernize: move existing Web, WinForms, and WPF apps to the cloud, improve performance, ship as a single executable, and weave in AI capabilities. |
|||
|
|||
On AI, he emphasized a human-centered stance: AI and agents should augment, not replace, developers. In the future, developers will orchestrate and govern agents, and human judgment will matter more than ever. He closed by thanking the open-source community for its many proposals and pull requests, stressing that .NET is an open-source platform built together by Microsoft and the community, and wishing everyone an inspiring conference and a joyful journey with .NET 10. |
|||
|
|||
 |
|||
|
|||
### Roundtable Discussion |
|||
|
|||
The roundtable discussion, titled “Empowering with AI, Breaking Through Cross-Platform Barriers, and Ecosystem Innovation,” focused on practical implementation. It explored typical paths for large models and intelligent agents in enterprises, key considerations for choosing cross-platform UI frameworks, and the evolution of these frameworks. Panelists discussed questions like: How can AI capabilities be integrated into existing business processes instead of creating an “experimental” pipeline? How should cross-platform solutions be evaluated in terms of performance, ecosystem, and team skillsets? What are the unique opportunities for domestic ecosystems in the global tech landscape? And how can community collaboration help developers quickly adopt best practices? A shared consensus emerged: in the short term, focus on running scenarios; in the long term, return to engineering fundamentals. Both toolchains and methodologies are equally important. |
|||
|
|||
 |
|||
|
|||
### In-Depth Sessions |
|||
|
|||
The afternoon featured four breakout sessions, covering a wide range of topics with deep dives into both foundational technologies and real-world project reviews: |
|||
|
|||
- **Frontend and Cross-Platform:** Focused on the progress of Avalonia, Blazor, and WebAssembly, as well as the integrated experience of .NET Aspire in multi-service applications. Speakers shared insights on reusing core logic between desktop and web, shortening cold start times with incremental compilation and resource trimming, and performance profiling and optimization in WASM scenarios. |
|||
- **AI Agents and Enterprise Adoption:** Discussed multi-agent orchestration, the MCP plugin ecosystem, and enterprise data compliance. From common pitfalls of “demo-level” AI to the “five-step method” for moving from POC to production, the session covered use cases like knowledge retrieval, process automation, intelligent customer service, and developer assistants, emphasizing evaluation metrics, prompt engineering, and monitoring governance. |
|||
- **.NET Practices and Engineering:** Focused on the latest capabilities and performance practices of EF Core, the boundaries of NativeAOT, automated testing strategies, and observability implementation. Discussions included database migration strategies, caching and concurrency control for hot paths, end-to-end tracing, and structured logging. |
|||
- **Solutions and Case Studies:** From Clean Architecture/DDD to AI-powered business evolution, topics included application modernization, SaaS transformation, and edge-cloud collaboration in AIoT. Speakers broke down modular governance, team collaboration, and release strategies for complex systems, putting “delivering value continuously” at the center stage. |
|||
|
|||
 |
|||
|
|||
## ABP Booth Highlights: Showcases, Conversations, and Fun |
|||
|
|||
The story of ABP began with a promise to create a better starting point. From the frustration of “copy-pasting boilerplate code,” we crafted a modular, opinionated framework. We chose open source and community collaboration. We founded Volosoft to turn our vision into reality with professional tools. Today, tens of thousands of developers explore the ABP framework, and thousands of teams rely on the ABP platform to deliver production-grade .NET applications faster and more securely. |
|||
|
|||
 |
|||
|
|||
At .NET Conf China 2025, we brought our “developer platform built for developers” to every visitor. Our booth demonstrations started with “a production-ready skeleton from the start”: modular layered architecture, built-in authentication and authorization systems, multi-tenancy support, audit logging, and localization—all out of the box. On the frontend and backend, ABP offers diverse options like MVC, Blazor, and Angular, enabling teams to quickly implement solutions on familiar stacks while maintaining flexibility for future evolution. We also showcased how ABP integrates with containerization, CI/CD, and observability, emphasizing “engineering built into the framework, not reinvented by every team.” |
|||
|
|||
 |
|||
|
|||
**Interaction and Prizes:** Sharing technology should also be warm and engaging. We hosted a QR code raffle at the booth, with prizes including ABP stickers, the book *Mastering ABP Framework*, and Bluetooth headphones. Multiple rounds of raffles and group photos made the interactions more memorable. Many developers shared their ABP experiences and plans for improvement right at the booth, and a few impromptu “code walkthroughs” naturally happened. The love and joy for technology were captured in every handshake and discussion. |
|||
|
|||
 |
|||
|
|||
## Looking Ahead: Building the Ecosystem Together |
|||
|
|||
From an open-source journey to a complete development platform for the future, we’ve always believed that developers deserve a better starting point. Around performance, intelligence, and cross-platform capabilities, we will continue investing in engineering, ecosystem collaboration, and best practice sharing. We also welcome more partners to contribute through documentation and examples, share your experiences, and submit your ideas. Together, let’s make “useful infrastructure” more stable, efficient, and business-friendly. |
|||
|
|||
We look forward to exchanging ideas, sharing practices, and building the ecosystem together at the next gathering. Technology meets creativity, and the possibilities are endless. We’re on the road and waiting for you at the next event. |
|||
|
|||
See you next year at .NET Conf China 2026! |
|||
|
|||
 |
|||
|
After Width: | Height: | Size: 396 KiB |
|
After Width: | Height: | Size: 502 KiB |
|
After Width: | Height: | Size: 432 KiB |
|
After Width: | Height: | Size: 328 KiB |
|
After Width: | Height: | Size: 524 KiB |
|
After Width: | Height: | Size: 378 KiB |
|
After Width: | Height: | Size: 671 KiB |
|
After Width: | Height: | Size: 399 KiB |
|
After Width: | Height: | Size: 103 KiB |
|
After Width: | Height: | Size: 93 KiB |
|
After Width: | Height: | Size: 7.0 KiB |
|
After Width: | Height: | Size: 4.1 KiB |
|
After Width: | Height: | Size: 7.8 KiB |
|
After Width: | Height: | Size: 7.5 KiB |
@ -0,0 +1,797 @@ |
|||
# Implement Automatic Method-Level Caching in ABP Framework |
|||
|
|||
Caching is one of the most effective ways to improve application performance, but implementing it manually for every method can be tedious and error-prone. What if you could cache method results automatically with just an attribute? In this article, we'll explore how to build an automatic method-level caching system in ABP Framework that handles cache invalidation, supports multiple scopes, and integrates seamlessly with your existing application. |
|||
|
|||
By the end of this guide, you'll understand how to implement attribute-based caching that automatically invalidates when entities change, supports user-specific and global caching scopes, and provides built-in metrics for monitoring cache performance. |
|||
|
|||
> 💡 **Complete Implementation Available**: This article is based on a working demo project. You can find the complete implementation in the [AbpAutoCacheDemo repository](https://github.com/salihozkara/AbpAutoCacheDemo), with the core AutoCache library implementation available in [this commit](https://github.com/salihozkara/AbpAutoCacheDemo/commit/946df1fc07de6eddd26eb14013a09968cd59329b). |
|||
|
|||
## What is Automatic Method-Level Caching? |
|||
|
|||
Automatic method-level caching is a technique that intercepts method calls and caches their results without requiring manual cache management code. Instead of writing cache logic in every method, you simply decorate methods with attributes that define caching behavior. |
|||
|
|||
 |
|||
|
|||
The key benefits include: |
|||
|
|||
- **Reduced Boilerplate:** No repetitive cache management code in your business logic |
|||
- **Consistent Caching Strategy:** Centralized cache configuration and behavior |
|||
- **Smart Invalidation:** Automatic cache clearing when related entities change |
|||
- **Multiple Scopes:** Support for global, user-specific, and entity-specific caching |
|||
- **Built-in Monitoring:** Track cache hits, misses, and performance metrics |
|||
|
|||
## Architecture Overview |
|||
|
|||
The automatic caching system consists of several key components working together: |
|||
|
|||
 |
|||
|
|||
**Core Components:** |
|||
|
|||
1. **CacheAttribute:** The attribute you apply to methods to enable automatic caching |
|||
2. **AutoCacheInterceptor:** Intercepts method calls and handles cache operations |
|||
3. **AutoCacheManager:** Manages cache storage, retrieval, and key generation |
|||
4. **IAutoCacheKeyManager:** Handles cache key mapping and invalidation |
|||
5. **AutoCacheInvalidationHandler:** Listens to entity changes and clears related caches |
|||
|
|||
This architecture leverages ABP's dynamic proxy system and event bus to provide seamless caching without modifying your business logic. |
|||
|
|||
## Prerequisites |
|||
|
|||
Before implementing automatic caching, ensure you have: |
|||
|
|||
- ABP Framework 10.0 or later |
|||
## Implementation |
|||
|
|||
> 📦 **Repository Structure**: The complete implementation is available in the [AbpAutoCacheDemo repository](https://github.com/salihozkara/AbpAutoCacheDemo). The AutoCache library is located in the `src/AutoCache` folder, making it easy to extract and reuse in your own projects. |
|||
|
|||
### Step - 1: Create the AutoCache Module |
|||
|
|||
First, let's create a separate module for our caching infrastructure. This makes it reusable across projects. |
|||
|
|||
### Step - 1: Create the AutoCache Module |
|||
|
|||
First, let's create a separate module for our caching infrastructure. This makes it reusable across projects. |
|||
|
|||
Create `AutoCache.csproj`: |
|||
|
|||
```xml |
|||
<Project Sdk="Microsoft.NET.Sdk"> |
|||
<PropertyGroup> |
|||
<TargetFramework>net10.0</TargetFramework> |
|||
<Nullable>enable</Nullable> |
|||
</PropertyGroup> |
|||
|
|||
<ItemGroup> |
|||
<PackageReference Include="Volo.Abp.Caching.StackExchangeRedis" Version="10.0.0" /> |
|||
<PackageReference Include="Volo.Abp.Core" Version="10.0.0" /> |
|||
<PackageReference Include="Volo.Abp.Ddd.Domain" Version="10.0.0" /> |
|||
</ItemGroup> |
|||
</Project> |
|||
``` |
|||
|
|||
Create the module class `AutoCacheModule.cs`: |
|||
|
|||
```csharp |
|||
using Microsoft.Extensions.DependencyInjection; |
|||
using Volo.Abp.Caching.StackExchangeRedis; |
|||
using Volo.Abp.Domain; |
|||
using Volo.Abp.Modularity; |
|||
|
|||
namespace AutoCache; |
|||
|
|||
[DependsOn(typeof(AbpDddDomainModule), typeof(AbpCachingStackExchangeRedisModule))] |
|||
public class AutoCacheModule : AbpModule |
|||
{ |
|||
public override void PreConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
context.Services.OnRegistered(AutoCacheRegister.RegisterInterceptorIfNeeded); // 👈 Register interceptor |
|||
} |
|||
} |
|||
``` |
|||
|
|||
This module automatically registers the cache interceptor for any class that uses the `CacheAttribute`. |
|||
|
|||
### Step - 2: Define the Cache Attribute |
|||
|
|||
The `CacheAttribute` is the core of our automatic caching system. It specifies which entities affect the cache and what scope to use. |
|||
|
|||
Create `CacheAttribute.cs`: |
|||
|
|||
```csharp |
|||
using System; |
|||
using Volo.Abp.Domain.Entities; |
|||
|
|||
namespace AutoCache; |
|||
|
|||
[AttributeUsage(AttributeTargets.Method)] |
|||
public class CacheAttribute : Attribute |
|||
{ |
|||
/// <summary> |
|||
/// Entity types that affect this cache. When these entities change, the cache will be invalidated. |
|||
/// </summary> |
|||
public Type[] InvalidateOnEntities { get; set; } |
|||
|
|||
/// <summary> |
|||
/// Scope of the cache (Global, CurrentUser, AuthenticatedUser, or Entity) |
|||
/// </summary> |
|||
public AutoCacheScope Scope { get; set; } = AutoCacheScope.Global; |
|||
|
|||
/// <summary> |
|||
/// Absolute expiration time relative to now in milliseconds (0 = use default, -1 = disabled) |
|||
/// </summary> |
|||
public long AbsoluteExpirationRelativeToNow { get; set; } |
|||
|
|||
/// <summary> |
|||
/// Sliding expiration time in milliseconds (0 = use default, -1 = disabled) |
|||
/// </summary> |
|||
public long SlidingExpiration { get; set; } |
|||
|
|||
public bool ConsiderUow { get; set; } |
|||
|
|||
public string AdditionalCacheKey { get; set; } |
|||
|
|||
public CacheAttribute(params Type[] invalidateOnEntities) // 👈 Specify entities that trigger cache invalidation |
|||
{ |
|||
foreach (var entityType in invalidateOnEntities) |
|||
{ |
|||
ArgumentNullException.ThrowIfNull(entityType); |
|||
if (!typeof(IEntity).IsAssignableFrom(entityType)) |
|||
{ |
|||
throw new ArgumentException($"Type {entityType.FullName} must implement IEntity interface."); |
|||
} |
|||
} |
|||
InvalidateOnEntities = invalidateOnEntities; |
|||
} |
|||
} |
|||
``` |
|||
|
|||
**Key Properties:** |
|||
|
|||
- **InvalidateOnEntities:** Array of entity types that, when modified, will clear this cache |
|||
- **Scope:** Determines cache visibility (Global, CurrentUser, AuthenticatedUser, Entity) |
|||
- **AbsoluteExpirationRelativeToNow / SlidingExpiration:** Control cache lifetime |
|||
|
|||
### Step - 3: Define Cache Scopes |
|||
|
|||
Cache scopes determine how cache entries are partitioned. Create `AutoCacheScope.cs`: |
|||
|
|||
```csharp |
|||
using System; |
|||
|
|||
namespace AutoCache; |
|||
|
|||
[Flags] |
|||
public enum AutoCacheScope |
|||
{ |
|||
/// <summary> |
|||
/// Cache is shared globally across all users |
|||
/// </summary> |
|||
Global, |
|||
|
|||
/// <summary> |
|||
/// Cache is scoped to the current user (based on user ID) |
|||
/// </summary> |
|||
CurrentUser, |
|||
|
|||
/// <summary> |
|||
/// Cache is scoped to authenticated vs unauthenticated users |
|||
/// </summary> |
|||
AuthenticatedUser, |
|||
|
|||
/// <summary> |
|||
/// Cache is scoped to the primary key of the entity involved |
|||
/// </summary> |
|||
Entity |
|||
} |
|||
``` |
|||
|
|||
 |
|||
|
|||
**When to Use Each Scope:** |
|||
|
|||
- **Global:** For data that's the same for all users (e.g., configuration, public lists) |
|||
- **CurrentUser:** For user-specific data (e.g., user profile, user's orders) |
|||
- **AuthenticatedUser:** For data that differs between authenticated and anonymous users |
|||
- **Entity:** For data tied to a specific entity instance (e.g., book details by ID) |
|||
|
|||
### Step - 4: Implement the Cache Interceptor |
|||
|
|||
The interceptor is the heart of automatic caching. It intercepts method calls, checks the cache, and stores results. Create `AutoCacheInterceptor.cs`: |
|||
|
|||
```csharp |
|||
using System; |
|||
using System.Collections.Concurrent; |
|||
using System.Linq; |
|||
using System.Reflection; |
|||
using System.Threading.Tasks; |
|||
using Microsoft.Extensions.Caching.Distributed; |
|||
using Microsoft.Extensions.Logging; |
|||
using Microsoft.Extensions.Options; |
|||
using Volo.Abp.DependencyInjection; |
|||
using Volo.Abp.DynamicProxy; |
|||
|
|||
namespace AutoCache; |
|||
|
|||
public class AutoCacheInterceptor : AbpInterceptor, ITransientDependency |
|||
{ |
|||
private readonly ILogger<AutoCacheInterceptor> _logger; |
|||
private readonly AutoCacheOptions _options; |
|||
private static readonly MethodInfo GetOrAddCacheAsyncMethod; |
|||
private readonly AutoCacheManager _autoCacheManager; |
|||
private static readonly ConcurrentDictionary<Type, MethodInfo> MethodCache = new(); |
|||
|
|||
static AutoCacheInterceptor() |
|||
{ |
|||
GetOrAddCacheAsyncMethod = typeof(AutoCacheInterceptor).GetMethod( |
|||
nameof(GetOrAddCacheAsync), |
|||
BindingFlags.NonPublic | BindingFlags.Instance |
|||
)!; |
|||
} |
|||
|
|||
public AutoCacheInterceptor( |
|||
ILogger<AutoCacheInterceptor> logger, |
|||
IOptions<AutoCacheOptions> options, |
|||
AutoCacheManager autoCacheManager) |
|||
{ |
|||
_logger = logger; |
|||
_autoCacheManager = autoCacheManager; |
|||
_options = options.Value; |
|||
} |
|||
|
|||
public override async Task InterceptAsync(IAbpMethodInvocation invocation) |
|||
{ |
|||
// Check if caching is enabled and method has [Cache] attribute |
|||
if(!_options.Enabled || |
|||
invocation.Method.GetCustomAttributes(typeof(CacheAttribute), true).FirstOrDefault() |
|||
is not CacheAttribute attribute) |
|||
{ |
|||
await invocation.ProceedAsync(); // 👈 No caching, proceed normally |
|||
return; |
|||
} |
|||
|
|||
var proceeded = false; |
|||
|
|||
try |
|||
{ |
|||
// Create generic method based on return type |
|||
var genericMethod = MethodCache.GetOrAdd(invocation.Method.ReturnType, t => |
|||
{ |
|||
var isGenericTask = t.IsGenericType && t.GetGenericTypeDefinition() == typeof(Task<>); |
|||
var resultType = isGenericTask ? t.GetGenericArguments()[0] : t; |
|||
return GetOrAddCacheAsyncMethod.MakeGenericMethod(resultType); |
|||
}); |
|||
|
|||
// Execute cache logic |
|||
(var result, proceeded) = await (Task<(object, bool)>)genericMethod.Invoke(this, [invocation, attribute])!; |
|||
invocation.ReturnValue = result; // 👈 Set cached or fresh result |
|||
} |
|||
catch (Exception e) |
|||
{ |
|||
_logger.LogError(e, "Error occurred while caching method {MethodName}", invocation.Method.Name); |
|||
|
|||
if(e is AutoCacheExceptionWrapper exceptionWrapper) |
|||
{ |
|||
if (_options.ThrowOnError) |
|||
{ |
|||
throw exceptionWrapper.OriginalException; |
|||
} |
|||
|
|||
_logger.LogWarning( |
|||
"Cache operation failed, falling back to method execution for {MethodName}", |
|||
invocation.Method.Name |
|||
); |
|||
} |
|||
|
|||
if (!proceeded && invocation.ReturnValue == null) |
|||
{ |
|||
await invocation.ProceedAsync(); // 👈 Fallback to actual method execution |
|||
} |
|||
} |
|||
} |
|||
|
|||
private async Task<(object?, bool)> GetOrAddCacheAsync<TResult>( |
|||
IAbpMethodInvocation invocation, |
|||
CacheAttribute attribute) |
|||
{ |
|||
var proceeded = false; |
|||
var result = await _autoCacheManager.GetOrAddAsync( |
|||
invocation.TargetObject, |
|||
Factory, |
|||
invocation.Arguments, |
|||
() => new DistributedCacheEntryOptions |
|||
{ |
|||
AbsoluteExpirationRelativeToNow = GetExpiration( |
|||
attribute.AbsoluteExpirationRelativeToNow, |
|||
_options.DefaultAbsoluteExpirationRelativeToNow), |
|||
SlidingExpiration = GetExpiration( |
|||
attribute.SlidingExpiration, |
|||
_options.DefaultSlidingExpiration) |
|||
}, |
|||
attribute.InvalidateOnEntities, |
|||
attribute.Scope, |
|||
attribute.ConsiderUow, |
|||
attribute.AdditionalCacheKey, |
|||
invocation.Method.Name); |
|||
|
|||
return (result, proceeded); |
|||
|
|||
async Task<TResult> Factory() |
|||
{ |
|||
await invocation.ProceedAsync(); // 👈 Execute actual method on cache miss |
|||
proceeded = true; |
|||
return (TResult)invocation.ReturnValue; |
|||
} |
|||
} |
|||
|
|||
private static TimeSpan? GetExpiration(long milliseconds, long defaultValue) |
|||
{ |
|||
return milliseconds switch |
|||
{ |
|||
0 => defaultValue > 0 ? TimeSpan.FromMilliseconds(defaultValue) : null, |
|||
< 0 => null, |
|||
_ => TimeSpan.FromMilliseconds(milliseconds) |
|||
}; |
|||
} |
|||
} |
|||
``` |
|||
|
|||
The interceptor intelligently determines whether to serve cached data or execute the actual method. |
|||
|
|||
### Step - 5: Implement the Cache Manager |
|||
|
|||
The `AutoCacheManager` handles the actual cache operations. Create a simplified version: |
|||
|
|||
```csharp |
|||
using System; |
|||
using System.Runtime.CompilerServices; |
|||
using System.Threading.Tasks; |
|||
using Microsoft.Extensions.Caching.Distributed; |
|||
using Microsoft.Extensions.Logging; |
|||
using Volo.Abp.DependencyInjection; |
|||
using Volo.Abp.DynamicProxy; |
|||
using Volo.Abp.Users; |
|||
|
|||
namespace AutoCache; |
|||
|
|||
public class AutoCacheManager : IScopedDependency |
|||
{ |
|||
private readonly IAutoCacheKeyManager _autoCacheKeyManager; |
|||
private readonly ICurrentUser _currentUser; |
|||
private readonly ILogger<AutoCacheManager> _logger; |
|||
private readonly IAutoCacheMetrics _metrics; |
|||
private readonly AutoCacheOptions _options; |
|||
|
|||
public AutoCacheManager( |
|||
IAutoCacheKeyManager autoCacheKeyManager, |
|||
ICurrentUser currentUser, |
|||
ILogger<AutoCacheManager> logger, |
|||
IAutoCacheMetrics metrics, |
|||
IOptions<AutoCacheOptions> options) |
|||
{ |
|||
_autoCacheKeyManager = autoCacheKeyManager; |
|||
_currentUser = currentUser; |
|||
_logger = logger; |
|||
_metrics = metrics; |
|||
_options = options.Value; |
|||
} |
|||
|
|||
public async Task<TResult> GetOrAddAsync<TResult>( |
|||
object? caller, |
|||
Func<Task<TResult>> func, |
|||
object?[]? parameters = null, |
|||
Func<DistributedCacheEntryOptions>? optionsFactory = null, |
|||
Type[]? invalidateOnEntities = null, |
|||
AutoCacheScope scope = AutoCacheScope.Global, |
|||
bool considerUow = false, |
|||
string? additionalCacheKey = null, |
|||
[CallerMemberName] string methodName = "") |
|||
{ |
|||
if (!_options.Enabled) |
|||
{ |
|||
return await func(); // 👈 Caching disabled, execute directly |
|||
} |
|||
|
|||
var callerType = caller != null ? ProxyHelper.GetUnProxiedType(caller) : GetType(); |
|||
parameters ??= []; |
|||
|
|||
// Generate unique cache key based on method, parameters, and scope |
|||
var cacheKey = GenerateCacheKey<TResult>( |
|||
callerType.Name, |
|||
additionalCacheKey, |
|||
methodName, |
|||
parameters, |
|||
scope); |
|||
|
|||
var (cachedResult, exception, wasHit) = await GetOrAddCacheAsync( |
|||
cacheKey, |
|||
func, |
|||
optionsFactory, |
|||
considerUow |
|||
); |
|||
|
|||
// Record metrics |
|||
if (wasHit) |
|||
{ |
|||
_metrics.RecordHit(cacheKey); |
|||
} |
|||
else |
|||
{ |
|||
_metrics.RecordMiss(cacheKey); |
|||
} |
|||
|
|||
if (exception != null) |
|||
{ |
|||
_metrics.RecordError(cacheKey, exception); |
|||
|
|||
if (_options.ThrowOnError) |
|||
{ |
|||
throw exception; |
|||
} |
|||
} |
|||
|
|||
return cachedResult; |
|||
} |
|||
|
|||
private string GenerateCacheKey<TResult>( |
|||
string callerTypeName, |
|||
string? additionalCacheKey, |
|||
string methodName, |
|||
object?[] parameters, |
|||
AutoCacheScope scope) |
|||
{ |
|||
var keyBuilder = new StringBuilder(); |
|||
keyBuilder.Append($"{callerTypeName}:{methodName}"); |
|||
|
|||
// Add parameters to key |
|||
foreach (var param in parameters) |
|||
{ |
|||
keyBuilder.Append($":{param}"); |
|||
} |
|||
|
|||
// Add scope-specific segments |
|||
if (scope.HasFlag(AutoCacheScope.CurrentUser) && _currentUser.Id.HasValue) |
|||
{ |
|||
keyBuilder.Append($":user:{_currentUser.Id}"); // 👈 User-specific cache key |
|||
} |
|||
|
|||
if (scope.HasFlag(AutoCacheScope.AuthenticatedUser)) |
|||
{ |
|||
keyBuilder.Append($":auth:{_currentUser.IsAuthenticated}"); |
|||
} |
|||
|
|||
if (!string.IsNullOrEmpty(additionalCacheKey)) |
|||
{ |
|||
keyBuilder.Append($":{additionalCacheKey}"); |
|||
} |
|||
|
|||
return keyBuilder.ToString(); |
|||
} |
|||
|
|||
// Additional methods for cache retrieval and storage... |
|||
} |
|||
``` |
|||
|
|||
The manager generates unique cache keys based on method signatures, parameters, and scope settings. |
|||
|
|||
### Step - 6: Implement Cache Invalidation |
|||
|
|||
When entities change, related caches must be cleared. Create `AutoCacheInvalidationHandler.cs`: |
|||
|
|||
```csharp |
|||
using System; |
|||
using System.Threading.Tasks; |
|||
using Microsoft.Extensions.Logging; |
|||
using Volo.Abp.Domain.Entities; |
|||
using Volo.Abp.Domain.Entities.Events; |
|||
using Volo.Abp.EventBus; |
|||
using Volo.Abp.Uow; |
|||
|
|||
namespace AutoCache; |
|||
|
|||
public class AutoCacheInvalidationHandler<TEntity> : |
|||
ILocalEventHandler<EntityChangedEventData<TEntity>> |
|||
where TEntity : class, IEntity |
|||
{ |
|||
private readonly IAutoCacheKeyManager _autoCacheKeyManager; |
|||
private readonly ILogger<AutoCacheInvalidationHandler<TEntity>> _logger; |
|||
private readonly IUnitOfWorkManager _unitOfWorkManager; |
|||
|
|||
public AutoCacheInvalidationHandler( |
|||
IAutoCacheKeyManager autoCacheKeyManager, |
|||
ILogger<AutoCacheInvalidationHandler<TEntity>> logger, |
|||
IUnitOfWorkManager unitOfWorkManager) |
|||
{ |
|||
_autoCacheKeyManager = autoCacheKeyManager; |
|||
_logger = logger; |
|||
_unitOfWorkManager = unitOfWorkManager; |
|||
} |
|||
|
|||
public async Task HandleEventAsync(EntityChangedEventData<TEntity> eventData) |
|||
{ |
|||
try |
|||
{ |
|||
var entityType = typeof(TEntity); |
|||
var context = new RemoveCacheKeyContext |
|||
{ |
|||
Keys = eventData.Entity.GetKeys()! |
|||
}; |
|||
|
|||
// Clear cache after unit of work completes |
|||
if(_unitOfWorkManager.Current != null) |
|||
{ |
|||
_unitOfWorkManager.Current.OnCompleted(async () => |
|||
{ |
|||
await _autoCacheKeyManager.RemoveCacheAndCacheKeys(entityType, context); // 👈 Invalidate cache |
|||
}); |
|||
} |
|||
else |
|||
{ |
|||
await _autoCacheKeyManager.RemoveCacheAndCacheKeys(entityType, context); |
|||
} |
|||
} |
|||
catch (Exception e) |
|||
{ |
|||
_logger.LogError( |
|||
e, |
|||
"Error occurred while clearing cache for entity type {EntityType}", |
|||
typeof(TEntity).FullName |
|||
); |
|||
} |
|||
} |
|||
} |
|||
``` |
|||
|
|||
 |
|||
|
|||
This handler listens to entity change events and automatically clears related caches. The invalidation happens after the unit of work completes to ensure data consistency. |
|||
|
|||
### Step - 7: Configure AutoCache in Your Application |
|||
|
|||
Add the `AutoCacheModule` to your application module dependencies: |
|||
|
|||
```csharp |
|||
[DependsOn( |
|||
typeof(AutoCacheModule), // 👈 Add AutoCache module |
|||
typeof(AbpCachingStackExchangeRedisModule), |
|||
// ... other modules |
|||
)] |
|||
public class YourApplicationModule : AbpModule |
|||
{ |
|||
public override void ConfigureServices(ServiceConfigurationContext context) |
|||
{ |
|||
Configure<AutoCacheOptions>(options => |
|||
{ |
|||
options.Enabled = true; // 👈 Enable caching |
|||
options.DefaultAbsoluteExpirationRelativeToNow = 3600000; // 1 hour |
|||
options.DefaultSlidingExpiration = 600000; // 10 minutes |
|||
options.ThrowOnError = false; // Fallback to method execution on cache errors |
|||
}); |
|||
|
|||
// Configure Redis (if using distributed cache) |
|||
Configure<AbpDistributedCacheOptions>(options => |
|||
{ |
|||
options.KeyPrefix = "YourApp:"; |
|||
}); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
### Step - 8: Use Automatic Caching in Application Services |
|||
|
|||
Now comes the easy part - using automatic caching! Simply add the `[Cache]` attribute to your methods: |
|||
|
|||
```csharp |
|||
using AutoCache; |
|||
|
|||
[Authorize(AutoCacheDemoPermissions.Books.Default)] |
|||
public class BookAppService : ApplicationService, IBookAppService |
|||
{ |
|||
private readonly IRepository<Book, Guid> _repository; |
|||
private readonly AutoCacheManager _autoCacheManager; |
|||
|
|||
public BookAppService(IRepository<Book, Guid> repository, AutoCacheManager autoCacheManager) |
|||
{ |
|||
_repository = repository; |
|||
_autoCacheManager = autoCacheManager; |
|||
} |
|||
|
|||
// Cache this method, invalidate when Book entity changes |
|||
[Cache(typeof(Book), Scope = AutoCacheScope.Global)] |
|||
public virtual async Task<BookDto> GetAsync(Guid id) |
|||
{ |
|||
// You can also use AutoCacheManager directly for nested caching |
|||
var book = await _autoCacheManager.GetOrAddAsync( |
|||
this, |
|||
async () => await _repository.GetAsync(id), |
|||
[id], // 👈 Method parameters |
|||
invalidateOnEntities: [typeof(Book)], |
|||
scope: AutoCacheScope.Entity); |
|||
|
|||
return ObjectMapper.Map<Book, BookDto>(book!); |
|||
} |
|||
|
|||
// Cache book list, invalidate when any Book changes |
|||
[Cache(typeof(Book))] |
|||
public virtual async Task<PagedResultDto<BookDto>> GetListAsync(PagedAndSortedResultRequestDto input) |
|||
{ |
|||
var queryable = await _repository.GetQueryableAsync(); |
|||
var query = queryable |
|||
.OrderBy(input.Sorting.IsNullOrWhiteSpace() ? "Name" : input.Sorting) |
|||
.Skip(input.SkipCount) |
|||
.Take(input.MaxResultCount); |
|||
|
|||
var books = await AsyncExecuter.ToListAsync(query); |
|||
var totalCount = await AsyncExecuter.CountAsync(queryable); |
|||
|
|||
return new PagedResultDto<BookDto>( |
|||
totalCount, |
|||
ObjectMapper.Map<List<Book>, List<BookDto>>(books) |
|||
); |
|||
} |
|||
|
|||
// No caching on write operations |
|||
[Authorize(AutoCacheDemoPermissions.Books.Create)] |
|||
public async Task<BookDto> CreateAsync(CreateUpdateBookDto input) |
|||
{ |
|||
var book = ObjectMapper.Map<CreateUpdateBookDto, Book>(input); |
|||
await _repository.InsertAsync(book); // 👈 This will trigger cache invalidation |
|||
return ObjectMapper.Map<Book, BookDto>(book); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
**What Happens Here:** |
|||
|
|||
1. When `GetAsync` is called, the interceptor checks the cache |
|||
2. On cache miss, the actual method executes and the result is cached |
|||
3. When `CreateAsync` inserts a `Book`, the invalidation handler clears all caches related to `Book` |
|||
4. Next call to `GetAsync` will fetch fresh data |
|||
|
|||
## Advanced Features |
|||
|
|||
### User-Specific Caching |
|||
|
|||
For user-specific data, use `AutoCacheScope.CurrentUser`: |
|||
|
|||
```csharp |
|||
[Cache(typeof(Order), Scope = AutoCacheScope.CurrentUser)] |
|||
public virtual async Task<List<OrderDto>> GetMyOrdersAsync() |
|||
{ |
|||
var orders = await _orderRepository.GetListAsync(x => x.UserId == CurrentUser.Id); |
|||
return ObjectMapper.Map<List<Order>, List<OrderDto>>(orders); |
|||
} |
|||
``` |
|||
|
|||
Each user gets their own cache entry, automatically invalidated when their orders change. |
|||
|
|||
### Custom Cache Keys |
|||
|
|||
For fine-grained control, add custom cache key segments: |
|||
|
|||
```csharp |
|||
[Cache( |
|||
typeof(Product), |
|||
Scope = AutoCacheScope.Global, |
|||
AdditionalCacheKey = "featured" |
|||
)] |
|||
public virtual async Task<List<ProductDto>> GetFeaturedProductsAsync() |
|||
{ |
|||
// Only featured products are cached separately |
|||
return await GetProductsByCategoryAsync("Featured"); |
|||
} |
|||
``` |
|||
|
|||
### Performance Metrics |
|||
|
|||
Monitor cache performance using `IAutoCacheMetrics`: |
|||
|
|||
```csharp |
|||
public class CacheMonitoringService : ITransientDependency |
|||
{ |
|||
private readonly IAutoCacheMetrics _metrics; |
|||
|
|||
public CacheMonitoringService(IAutoCacheMetrics metrics) |
|||
{ |
|||
_metrics = metrics; |
|||
} |
|||
|
|||
public AutoCacheStatistics GetStatistics() |
|||
{ |
|||
return _metrics.GetStatistics(); // 👈 Get hit rate, miss count, error count |
|||
} |
|||
} |
|||
``` |
|||
|
|||
## Testing the Application |
|||
|
|||
### 1. Run the Application |
|||
|
|||
```bash |
|||
abp new BookStore -u mvc -d ef |
|||
cd BookStore |
|||
dotnet run --project src/BookStore.Web |
|||
``` |
|||
|
|||
### 2. Test Cache Behavior |
|||
|
|||
Create a simple test to verify caching: |
|||
|
|||
```csharp |
|||
[Fact] |
|||
public async Task Should_Cache_Book_Results() |
|||
{ |
|||
// First call - cache miss |
|||
var book1 = await _bookAppService.GetAsync(testBookId); |
|||
|
|||
// Second call - cache hit (should be faster) |
|||
var book2 = await _bookAppService.GetAsync(testBookId); |
|||
|
|||
book1.Name.ShouldBe(book2.Name); |
|||
} |
|||
|
|||
[Fact] |
|||
public async Task Should_Invalidate_Cache_On_Update() |
|||
{ |
|||
// Cache the book |
|||
var book1 = await _bookAppService.GetAsync(testBookId); |
|||
|
|||
// Update the book |
|||
await _bookAppService.UpdateAsync(testBookId, new CreateUpdateBookDto |
|||
{ |
|||
Name = "Updated Name" |
|||
}); |
|||
|
|||
// Fetch again - should get updated data (cache was invalidated) |
|||
var book2 = await _bookAppService.GetAsync(testBookId); |
|||
|
|||
book2.Name.ShouldBe("Updated Name"); |
|||
} |
|||
``` |
|||
|
|||
### 3. Monitor Cache Performance |
|||
|
|||
Check your application logs for cache metrics: |
|||
|
|||
``` |
|||
[INF] Cache Hit: BookAppService:GetAsync:book-id-123 (Response Time: 5ms) |
|||
[INF] Cache Miss: BookAppService:GetListAsync (Response Time: 156ms) |
|||
[INF] Cache Invalidation: Book entity changed, cleared 3 cache entries |
|||
``` |
|||
|
|||
## Key Takeaways |
|||
|
|||
✅ **Automatic caching reduces boilerplate code** - Just add `[Cache]` attribute to methods instead of manual cache management |
|||
|
|||
✅ **Smart invalidation keeps data fresh** - Entity changes automatically clear related caches without manual intervention |
|||
|
|||
✅ **Multiple scoping options** - Support for global, user-specific, authenticated, and entity-level caching strategies |
|||
|
|||
✅ **Built-in fallback handling** - Gracefully falls back to method execution if caching fails |
|||
|
|||
✅ **Performance monitoring** - Track cache hits, misses, and errors for optimization |
|||
|
|||
## Conclusion |
|||
|
|||
Automatic method-level caching dramatically simplifies performance optimization in ABP Framework applications. By using attributes and interceptors, you can add sophisticated caching behavior without cluttering your business logic with cache management code. |
|||
|
|||
The system we've built provides intelligent cache invalidation, multiple scoping strategies, and built-in monitoring - all while maintaining clean, readable code. Whether you're building a small application or an enterprise system, this approach scales elegantly and integrates seamlessly with ABP's architecture. |
|||
|
|||
Ready to implement this in your project? The complete working implementation is available in the [AbpAutoCacheDemo repository](https://github.com/salihozkara/AbpAutoCacheDemo). You can clone the repository, explore the code, and even extract the `src/AutoCache` folder to use it as a standalone library in your own ABP applications. The [main implementation commit](https://github.com/salihozkara/AbpAutoCacheDemo/commit/946df1fc07de6eddd26eb14013a09968cd59329b) shows all the components working together, including interceptor registration, cache key management, and automatic invalidation handlers.r you're building a small application or an enterprise system, this approach scales elegantly and integrates seamlessly with ABP's architecture. |
|||
|
|||
Ready to implement this in your project? Check out the complete working example in the repository linked below, and start improving your application's performance today! |
|||
|
|||
### See Also |
|||
|
|||
- [ABP Caching Documentation](https://abp.io/docs/latest/framework/fundamentals/caching) |
|||
- [Interceptors in ABP](https://abp.io/docs/latest/framework/infrastructure/interceptors) |
|||
- [Event Bus Documentation](https://abp.io/docs/latest/framework/infrastructure/event-bus) |
|||
- [Sample Project on GitHub](https://github.com/salihozkara/AbpAutoCacheDemo) |
|||
|
|||
--- |
|||
|
|||
## References |
|||
|
|||
- [ABP Framework Documentation](https://docs.abp.io) |
|||
- [Redis Distributed Caching](https://redis.io/docs/) |
|||
- [Aspect-Oriented Programming Patterns](https://en.wikipedia.org/wiki/Aspect-oriented_programming) |
|||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue