mirror of https://github.com/abpframework/abp.git
sumeyye
3 months ago
206 changed files with 3188 additions and 1659 deletions
@ -0,0 +1,71 @@ |
|||||
|
# ABP.IO Platform 10.5 Final Has Been Released! |
||||
|
|
||||
|
We are glad to announce that [ABP](https://abp.io/) 10.5 stable version has been released. |
||||
|
|
||||
|
## What's New With Version 10.5? |
||||
|
|
||||
|
All the new features were explained in detail in the [10.5 RC Announcement Post](https://abp.io/community/announcements/announcing-abp-10-5-release-candidate-k6oxdfle), so there is no need to review them again. You can check it out for more details. |
||||
|
|
||||
|
## Getting Started with 10.5 |
||||
|
|
||||
|
### 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 no explicitly marked breaking changes in this version. However, there are still some important migration notes for specific scenarios. Please read the migration guide carefully, if you are upgrading from v10.4 or earlier versions: [ABP Version 10.5 Migration Guide](https://abp.io/docs/10.5/release-info/migration-guides/abp-10-5) |
||||
|
|
||||
|
## Community News |
||||
|
|
||||
|
### New ABP Community Articles |
||||
|
|
||||
|
As always, exciting articles have been contributed by the ABP community. I will highlight some of them here: |
||||
|
|
||||
|
- [Sumeyye Kurtulus](https://abp.io/community/members/sumeyye.kurtulus) has published 2 new articles: |
||||
|
- [Angular 22 State Management: Signals, SignalStore, or NgRx?](https://abp.io/community/articles/angular-22-state-management-signals-signalstore-or-ngrx-yq8zg0nw) |
||||
|
- [Customizing the ABP Framework: A Developer's Guide to LeptonX Theme Overrides in Angular and the Transition to React UI](https://abp.io/community/articles/customizing-the-abp-framework-a-developers-guide-to-nklweri3) |
||||
|
- [Working with Dapr Workflows in the ABP Framework](https://abp.io/community/articles/working-with-dapr-workflows-in-the-abp-framework-6476or18) by [Engincan Veske](https://abp.io/community/members/EngincanV) |
||||
|
- [Alper Ebicoglu](https://abp.io/community/members/alper) has published 2 new articles: |
||||
|
- [My Speaker's View of CONVEX Summit 2026](https://abp.io/community/articles/my-speakers-view-of-convex-summit-2026-ai-net-conference-3uk6ln1l) |
||||
|
- [AI Isn't Replacing Developers - It's Changing What Good Developers Spend Time On](https://abp.io/community/articles/ai-isnt-replacing-developers-its-changing-what-good-2016q6ng) |
||||
|
- [Deep Dive on ABP AI Agent: The Complete Series](https://abp.io/community/articles/deep-dive-on-abp-ai-agent-the-complete-series-f7jute7n) by [Berkan Sasmaz](https://abp.io/community/members/berkansasmaz) |
||||
|
- We have created a deep-dive series for ABP Studio's AI Coding Agent. You can read this series to learn the main features of the AI Coding Agent and how it can help you while developing ABP-based solutions. |
||||
|
|
||||
|
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.6. 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: 478 KiB |
|
After Width: | Height: | Size: 16 KiB |
Binary file not shown.
@ -0,0 +1,419 @@ |
|||||
|
# Working with Dapr Workflows in the ABP Framework |
||||
|
|
||||
|
Most real business processes don't finish in a single request. |
||||
|
|
||||
|
An order gets placed, inventory gets checked, a payment gets charged, and the customer gets notified. Each step can fail, time out, or need a retry. And the whole thing has to survive a process restart without losing its place or charging someone twice. |
||||
|
|
||||
|
We usually solve this with a pile of queues, a state table, and a lot of defensive code to track where each process is. It works, but the business logic ends up scattered across handlers and database rows, and nobody can read the flow top to bottom anymore. |
||||
|
|
||||
|
[I covered **Elsa** in two earlier articles](https://abp.io/community/search?tag=elsa) as one way to handle workflows in ABP. **Dapr Workflow** takes a different path: instead of an in-app engine, the workflow engine runs in the [**Dapr sidecar**](https://docs.dapr.io/concepts/dapr-services/sidecar/), and you write the process as ordinary C# code that Dapr makes durable. If the host crashes halfway through, the workflow picks up right where it left off. |
||||
|
|
||||
|
In this article, we'll build a small Dapr Workflow inside a fresh ABP project and run it end to end. By the time you reach the bottom, you should be able to copy the code, run it, and watch a workflow march through its steps. |
||||
|
|
||||
|
> **Note:** Versions matter here, because both ABP and Dapr move fast. This article is written in June 2026 against **ABP 10.4** (.NET 10), **Dapr 1.18**, and the **`Dapr.Workflow` 1.18.x** package. The `Dapr.Workflow` package was rewritten in Dapr 1.17, so older tutorials you find online may use a different API. |
||||
|
|
||||
|
## What Dapr Workflow Actually Is? |
||||
|
|
||||
|
You define a [**workflow**](https://docs.dapr.io/developing-applications/building-blocks/workflow/) that orchestrates a process, and [**activities**](https://docs.dapr.io/developing-applications/building-blocks/workflow/workflow-overview/#workflows-and-activities) that do the actual work (call a database, hit an API, send an email). |
||||
|
|
||||
|
> **This is orchestration rather than choreography:** one place drives the process, instead of services reacting to each other's events. The definitions live in your app, but the engine that executes them runs in the Dapr sidecar next to it. |
||||
|
|
||||
|
 |
||||
|
|
||||
|
The key idea is **durable execution**. Dapr records every step to a state store, so the workflow can be replayed from history at any time. A crash, a deployment, or a scale-out event doesn't lose progress, and a workflow can run for seconds or for months. |
||||
|
|
||||
|
> ⚠️ One rule follows from this: **workflow code must be deterministic**. No `DateTime.Now`, no random values, no direct I/O. Anything non-deterministic goes into an activity. Even logging is affected, so inside a workflow you use `context.CreateReplaySafeLogger<T>()` instead of a normal logger, otherwise every replay repeats your log lines. |
||||
|
|
||||
|
Under the hood, this all runs on [**Dapr actors**](https://docs.dapr.io/developing-applications/building-blocks/actors/actors-overview/), which is why the state store has to support actors. The good news is that the default local setup already handles this, as you'll see in a moment. |
||||
|
|
||||
|
--- |
||||
|
|
||||
|
## A Quick Note on ABP and Dapr |
||||
|
|
||||
|
ABP already ships a set of Dapr integration packages: `Volo.Abp.Dapr` (the core package), `Volo.Abp.EventBus.Dapr` and `Volo.Abp.AspNetCore.Mvc.Dapr.EventBus` (distributed event bus over Dapr pub/sub), `Volo.Abp.Http.Client.Dapr` (service invocation), and `Volo.Abp.DistributedLocking.Dapr` (distributed locking). You can read all about them in the [ABP Dapr integration documentation](https://abp.io/docs/latest/framework/dapr). |
||||
|
|
||||
|
These cover pub/sub, service-to-service calls, and locking. **Workflows are not part of ABP's Dapr integration**, and that's fine. Dapr Workflow has its own first-class .NET SDK (`Dapr.Workflow`), and you plug it straight into your ABP app like any other .NET library. So in this article we use the Dapr SDK directly, inside an ABP startup template. |
||||
|
|
||||
|
> **Note:** If you'd like to see deeper Dapr integration in ABP, or you'd like us to build a dedicated piece around Dapr Workflow, feel free to open a new issue on the [ABP GitHub repository](https://github.com/abpframework/abp/issues). Telling us what you need is the best way to help us prioritize it. |
||||
|
|
||||
|
--- |
||||
|
|
||||
|
## What We'll Build |
||||
|
|
||||
|
To keep this concrete, we'll build a small **order processing** workflow, the classic example for this kind of thing. |
||||
|
|
||||
|
The workflow takes an order, checks inventory, charges the customer, then notifies them. If the item is out of stock, it stops early and returns a rejected result. Nothing fancy on the business side, but it's enough to show the parts that matter: how a workflow chains activities, how state survives across steps, and how you start and track an instance. |
||||
|
|
||||
|
Here's the flow we're aiming for: |
||||
|
|
||||
|
- An order comes in with a product, a quantity, and a price |
||||
|
- **Check inventory**: if there isn't enough stock, reject the order and stop |
||||
|
- **Process payment**: charge the customer |
||||
|
- **Notify the customer**: let them know the order went through |
||||
|
- Return a final result |
||||
|
|
||||
|
Each of those steps will be an **activity**, and the workflow is the code that orchestrates them. Let's set up the project and build it. |
||||
|
|
||||
|
## Prerequisites |
||||
|
|
||||
|
Before we start, make sure you have these installed: |
||||
|
|
||||
|
- **.NET 10 SDK** |
||||
|
- **ABP CLI** (the current Studio CLI). Install it with `dotnet tool install -g Volo.Abp.Studio.Cli` (or update with `dotnet tool update -g Volo.Abp.Studio.Cli`) |
||||
|
- **Docker**, running on your machine |
||||
|
- [**Dapr CLI**, initialized once with `dapr init`](https://docs.dapr.io/getting-started/) |
||||
|
|
||||
|
That last step matters. When you run `dapr init` in self-hosted mode, Dapr pulls a few containers (including Redis) and writes a default `statestore.yaml` component. That default state store already has `actorStateStore: "true"` set, which is exactly what Dapr Workflow needs. So once `dapr init` finishes, you can run workflows locally with zero extra configuration. |
||||
|
|
||||
|
 |
||||
|
|
||||
|
> **Pro Tip:** If you ever swap the default Redis store for your own component, double-check that it sets `actorStateStore: "true"`. Without it, workflows silently fail to start, and it's the line people forget most often. |
||||
|
|
||||
|
## Create the Project |
||||
|
|
||||
|
In this article I'll create a new layered solution with **EF Core** as the database provider, using the ABP CLI. |
||||
|
|
||||
|
> If you already have an ABP project, you don't need a new one. You can apply the following steps to your existing solution and skip this section. |
||||
|
|
||||
|
Create a new solution named `DaprWorkflowDemo` (or whatever you want): |
||||
|
|
||||
|
```bash |
||||
|
abp new DaprWorkflowDemo |
||||
|
``` |
||||
|
|
||||
|
Once the download finishes, your project boilerplate is ready. Open the solution in your IDE and run the `DaprWorkflowDemo.Web` project once to confirm the app starts and the UI works. |
||||
|
|
||||
|
> Since, we have created the solution via ABP Studio CLI, it automatically runs the initial-tasks, which init database, seed initial data and run `abp install-libs` command, so, no need run the **DbMigrator* project. |
||||
|
|
||||
|
> Default admin username is **admin** and the password is **1q2w3E***. You can use these credentials to login... |
||||
|
|
||||
|
We'll do all the workflow work inside the `DaprWorkflowDemo.Web` project, since that's the running host where the workflow engine connects to the sidecar. |
||||
|
|
||||
|
## Install the Dapr.Workflow Package |
||||
|
|
||||
|
Open a terminal in the `DaprWorkflowDemo.Web` project folder and add the package: |
||||
|
|
||||
|
```bash |
||||
|
dotnet add package Dapr.Workflow |
||||
|
``` |
||||
|
|
||||
|
-> **This single package gives you everything:** the base `Workflow<TInput, TOutput>` and `WorkflowActivity<TInput, TOutput>` types, the `AddDaprWorkflow` registration helper, and the `DaprWorkflowClient` you use to start and query workflows from code. |
||||
|
|
||||
|
## Define the Workflow and Its Activities |
||||
|
|
||||
|
Now let's write the order processing flow we sketched out earlier. |
||||
|
|
||||
|
First, create a `Workflows` folder in the `DaprWorkflowDemo.Web` project. We'll keep everything there for simplicity. |
||||
|
|
||||
|
Every input and output in a workflow gets serialized to the state store, so the types you pass around should be simple, JSON-friendly records (**_ensure they are serializable!_**). Let's define them: |
||||
|
|
||||
|
```csharp |
||||
|
namespace DaprWorkflowDemo.Web.Workflows; |
||||
|
|
||||
|
public record OrderPayload(string OrderId, string ProductName, int Quantity, decimal TotalPrice); |
||||
|
|
||||
|
public record InventoryResult(bool InStock); |
||||
|
|
||||
|
public record OrderResult(string OrderId, string Status); |
||||
|
``` |
||||
|
|
||||
|
Now the workflow itself. A workflow derives from `Workflow<TInput, TOutput>` and reads top to bottom like a normal method, even though every step is durably persisted: |
||||
|
|
||||
|
```csharp |
||||
|
using Dapr.Workflow; |
||||
|
using Microsoft.Extensions.Logging; |
||||
|
using System.Threading.Tasks; |
||||
|
|
||||
|
namespace DaprWorkflowDemo.Web.Workflows; |
||||
|
|
||||
|
public class OrderProcessingWorkflow : Workflow<OrderPayload, OrderResult> |
||||
|
{ |
||||
|
public override async Task<OrderResult> RunAsync(WorkflowContext context, OrderPayload order) |
||||
|
{ |
||||
|
var logger = context.CreateReplaySafeLogger<OrderProcessingWorkflow>(); |
||||
|
logger.LogInformation("Starting order {OrderId}: {Quantity} x {ProductName}", |
||||
|
order.OrderId, order.Quantity, order.ProductName); |
||||
|
|
||||
|
// 1. Check inventory |
||||
|
var inventory = await context.CallActivityAsync<InventoryResult>( |
||||
|
nameof(CheckInventoryActivity), order); |
||||
|
|
||||
|
if (!inventory.InStock) |
||||
|
{ |
||||
|
logger.LogWarning("Order {OrderId} rejected: out of stock", order.OrderId); |
||||
|
return new OrderResult(order.OrderId, "Rejected: out of stock"); |
||||
|
} |
||||
|
|
||||
|
// 2. Process the payment |
||||
|
await context.CallActivityAsync(nameof(ProcessPaymentActivity), order); |
||||
|
|
||||
|
// 3. Notify the customer |
||||
|
await context.CallActivityAsync(nameof(NotifyCustomerActivity), order); |
||||
|
|
||||
|
logger.LogInformation("Order {OrderId} completed", order.OrderId); |
||||
|
return new OrderResult(order.OrderId, "Completed"); |
||||
|
} |
||||
|
} |
||||
|
``` |
||||
|
|
||||
|
A couple of things worth pointing out here. |
||||
|
|
||||
|
- `CallActivityAsync` does not invoke the activity directly. It schedules the work with the workflow engine, which records the result once the activity completes. If the process dies right after the payment step, Dapr replays the workflow, feeds it the already-recorded results for the completed steps, and resumes at the notification step. The customer never gets charged twice. This is the **task chaining** pattern. |
||||
|
- Notice the replay-safe logger too. Because the engine replays the workflow to rebuild its state, a normal logger would print the same lines over and over. `context.CreateReplaySafeLogger<T>()` logs only on the first real pass. |
||||
|
- Now the activities. An activity is where the real work happens, and the only place you're allowed to be non-deterministic. It derives from `WorkflowActivity<TInput, TOutput>` and supports constructor injection, so you can pull in your ABP services, repositories, or any registered dependency: |
||||
|
|
||||
|
```csharp |
||||
|
using Dapr.Workflow; |
||||
|
using Microsoft.Extensions.Logging; |
||||
|
using System.Threading.Tasks; |
||||
|
|
||||
|
namespace DaprWorkflowDemo.Web.Workflows; |
||||
|
|
||||
|
public class CheckInventoryActivity : WorkflowActivity<OrderPayload, InventoryResult> |
||||
|
{ |
||||
|
private readonly ILogger<CheckInventoryActivity> _logger; |
||||
|
|
||||
|
public CheckInventoryActivity(ILogger<CheckInventoryActivity> logger) |
||||
|
{ |
||||
|
_logger = logger; |
||||
|
} |
||||
|
|
||||
|
public override Task<InventoryResult> RunAsync(WorkflowActivityContext context, OrderPayload order) |
||||
|
{ |
||||
|
_logger.LogInformation("Checking inventory for {ProductName}", order.ProductName); |
||||
|
|
||||
|
// Pretend we queried a stock service or a repository here. |
||||
|
var inStock = order.Quantity <= 100; |
||||
|
|
||||
|
return Task.FromResult(new InventoryResult(inStock)); |
||||
|
} |
||||
|
} |
||||
|
|
||||
|
public class ProcessPaymentActivity : WorkflowActivity<OrderPayload, object?> |
||||
|
{ |
||||
|
private readonly ILogger<ProcessPaymentActivity> _logger; |
||||
|
|
||||
|
public ProcessPaymentActivity(ILogger<ProcessPaymentActivity> logger) |
||||
|
{ |
||||
|
_logger = logger; |
||||
|
} |
||||
|
|
||||
|
public override Task<object?> RunAsync(WorkflowActivityContext context, OrderPayload order) |
||||
|
{ |
||||
|
_logger.LogInformation("Charging {TotalPrice:C} for order {OrderId}", |
||||
|
order.TotalPrice, order.OrderId); |
||||
|
|
||||
|
// Call your real payment provider here. |
||||
|
return Task.FromResult<object?>(null); |
||||
|
} |
||||
|
} |
||||
|
|
||||
|
public class NotifyCustomerActivity : WorkflowActivity<OrderPayload, object?> |
||||
|
{ |
||||
|
private readonly ILogger<NotifyCustomerActivity> _logger; |
||||
|
|
||||
|
public NotifyCustomerActivity(ILogger<NotifyCustomerActivity> logger) |
||||
|
{ |
||||
|
_logger = logger; |
||||
|
} |
||||
|
|
||||
|
public override Task<object?> RunAsync(WorkflowActivityContext context, OrderPayload order) |
||||
|
{ |
||||
|
_logger.LogInformation("Notifying customer about order {OrderId}", order.OrderId); |
||||
|
|
||||
|
// Send an email, push a notification, publish an event, etc. |
||||
|
return Task.FromResult<object?>(null); |
||||
|
} |
||||
|
} |
||||
|
``` |
||||
|
|
||||
|
Each activity is isolated, so Dapr can retry a failed one without re-running the whole workflow. The two activities that don't return anything useful use `object?` as their output type and return `null`. That's why the workflow calls them with the non-generic `CallActivityAsync`, which ignores the result. |
||||
|
|
||||
|
Here's the shape of the process we just wrote: |
||||
|
|
||||
|
 |
||||
|
|
||||
|
## Register the Workflow |
||||
|
|
||||
|
Workflows and activities need to be registered so the engine knows about them. Open your `DaprWorkflowDemoWebModule` class and register them in `ConfigureServices`. Most of the existing code is abbreviated for simplicity: |
||||
|
|
||||
|
```csharp |
||||
|
using DaprWorkflowDemo.Web.Workflows; |
||||
|
using Dapr.Workflow; |
||||
|
|
||||
|
public override void ConfigureServices(ServiceConfigurationContext context) |
||||
|
{ |
||||
|
var hostingEnvironment = context.Services.GetHostingEnvironment(); |
||||
|
var configuration = context.Services.GetConfiguration(); |
||||
|
|
||||
|
// ... existing ABP configuration ... |
||||
|
|
||||
|
//Configure Dapr Workflows... |
||||
|
context.Services.AddDaprWorkflow(options => |
||||
|
{ |
||||
|
options.RegisterWorkflow<OrderProcessingWorkflow>(); |
||||
|
|
||||
|
options.RegisterActivity<CheckInventoryActivity>(); |
||||
|
options.RegisterActivity<ProcessPaymentActivity>(); |
||||
|
options.RegisterActivity<NotifyCustomerActivity>(); |
||||
|
}); |
||||
|
} |
||||
|
``` |
||||
|
|
||||
|
> `AddDaprWorkflow` does two things for us. It registers a background worker that connects to the sidecar's workflow engine and hosts your workflow definitions, and it registers a `DaprWorkflowClient` in the dependency injection container so you can start and query workflows from your own code later. |
||||
|
|
||||
|
That's all the wiring. There's no component YAML to write, because Dapr ships a built-in workflow component named `dapr` that runs on top of the actor state store we already have. |
||||
|
|
||||
|
## Run It With the Dapr Sidecar |
||||
|
|
||||
|
Here's the part that's different from a normal `dotnet run`. The workflow engine lives in the Dapr sidecar, so the app has to run **alongside** a sidecar. The Dapr CLI handles that for us. |
||||
|
|
||||
|
> In this section, I assume that you already run `dapr init` command before, as explained above. If you haven't run it yet, please first run it and then follow the instructions/commands below. |
||||
|
|
||||
|
First, make sure your database is migrated (run `DaprWorkflowDemo.DbMigrator` if you haven't). Then, from the `DaprWorkflowDemo.Web` project folder, start the app with Dapr: |
||||
|
|
||||
|
```bash |
||||
|
dapr run --app-id dapr-workflow-demo --dapr-http-port 3500 -- dotnet run |
||||
|
``` |
||||
|
|
||||
|
A few notes on this command: |
||||
|
|
||||
|
- `--app-id` is the identity of your app within Dapr. We'll use it nowhere else in this example, but Dapr needs it. |
||||
|
- `--dapr-http-port 3500` pins the sidecar's HTTP port so we know where to send requests. You can leave it out and let Dapr pick one, but pinning it keeps the next step simple. |
||||
|
- Everything after `--` is the command Dapr runs for your app. `dapr run` injects the sidecar's connection details (like the gRPC port) as environment variables, and the `Dapr.Workflow` worker reads them automatically to connect to the engine. |
||||
|
|
||||
|
Notice we don't pass `--app-port` here. That flag is only needed when Dapr has to call **into** your app (for pub/sub or service invocation). For workflows, your app connects **out** to the sidecar over gRPC, so we don't need it for this scenario. |
||||
|
|
||||
|
Once it's running, you'll see both the ABP app logs and the Dapr sidecar logs in the same terminal. |
||||
|
|
||||
|
## Does It Actually Work? |
||||
|
|
||||
|
The quickest way to test is to talk to the sidecar's **Workflow management HTTP API** directly. This hits Dapr, not your app, which makes it a clean smoke test with no extra endpoint code. |
||||
|
|
||||
|
Start a workflow instance. The component name is `dapr` (the built-in one), the workflow name is the class name, and we pass our own instance ID so it's easy to query: |
||||
|
|
||||
|
```bash |
||||
|
curl -i -X POST "http://localhost:3500/v1.0/workflows/dapr/OrderProcessingWorkflow/start?instanceID=order-001" \ |
||||
|
-H "Content-Type: application/json" \ |
||||
|
-d '{"OrderId":"order-001","ProductName":"Mechanical Keyboard","Quantity":2,"TotalPrice":59.90}' |
||||
|
``` |
||||
|
|
||||
|
The request body is the workflow input, and Dapr passes it straight through to your `OrderPayload`. You should get a `202 Accepted` back with the instance ID: |
||||
|
|
||||
|
```json |
||||
|
{ "instanceID": "order-001" } |
||||
|
``` |
||||
|
|
||||
|
Now query the status of that instance: |
||||
|
|
||||
|
```bash |
||||
|
curl "http://localhost:3500/v1.0/workflows/dapr/order-001" |
||||
|
``` |
||||
|
|
||||
|
After the workflow finishes, you'll see a `COMPLETED` status along with the serialized output: |
||||
|
|
||||
|
```json |
||||
|
{ |
||||
|
"instanceID": "order-001", |
||||
|
"workflowName": "OrderProcessingWorkflow", |
||||
|
"createdAt": "2026-06-29T15:30:15.038490Z", |
||||
|
"lastUpdatedAt": "2026-06-29T15:30:15.360885500Z", |
||||
|
"runtimeStatus": "COMPLETED", |
||||
|
"properties": { |
||||
|
"dapr.workflow.input": "{\"ProductName\":\"Mechanical Keyboard\",\"Quantity\":2,\"OrderId\":\"order-001\",\"TotalPrice\":59.9}", |
||||
|
"dapr.workflow.output": "{\"orderId\":\"order-001\",\"status\":\"Completed\"}" |
||||
|
} |
||||
|
} |
||||
|
``` |
||||
|
|
||||
|
If you check the terminal, you'll also see the log lines from the workflow and each activity in order: |
||||
|
|
||||
|
 |
||||
|
|
||||
|
The same management API also lets you `terminate`, `pause`, `resume`, and `purge` instances, and `raiseEvent` to send external events into a waiting workflow. For example: |
||||
|
|
||||
|
```bash |
||||
|
# Permanently delete a finished workflow's state |
||||
|
curl -X POST "http://localhost:3500/v1.0/workflows/dapr/order-001/purge" |
||||
|
``` |
||||
|
|
||||
|
The `DaprWorkflowClient` exposes the same operations in code (terminating, suspending and resuming, purging, and raising external events on an instance), which is the way to go for anything beyond a quick manual test. |
||||
|
|
||||
|
## Triggering Workflows From Your ABP Code |
||||
|
|
||||
|
Hitting the sidecar API by hand is great for a quick check, but in a real app you'll start workflows from your own code, and this is the recommended path. That's what the `DaprWorkflowClient` is for, and `AddDaprWorkflow` already registered it for you. |
||||
|
|
||||
|
You can inject it anywhere, for example into a controller or an application service. Here's a minimal controller in the `DaprWorkflowDemo.Web` project that starts an order and reads its status: |
||||
|
|
||||
|
```csharp |
||||
|
using System.Threading.Tasks; |
||||
|
using DaprWorkflowDemo.Web.Workflows; |
||||
|
using Dapr.Workflow; |
||||
|
using Microsoft.AspNetCore.Mvc; |
||||
|
|
||||
|
namespace DaprWorkflowDemo.Web.Controllers; |
||||
|
|
||||
|
[ApiController] |
||||
|
[Route("api/orders")] |
||||
|
public class OrderController : ControllerBase |
||||
|
{ |
||||
|
private readonly DaprWorkflowClient _workflowClient; |
||||
|
|
||||
|
public OrderController(DaprWorkflowClient workflowClient) |
||||
|
{ |
||||
|
_workflowClient = workflowClient; |
||||
|
} |
||||
|
|
||||
|
[HttpPost] |
||||
|
public async Task<IActionResult> StartAsync(OrderPayload order) |
||||
|
{ |
||||
|
var instanceId = await _workflowClient.ScheduleNewWorkflowAsync( |
||||
|
name: nameof(OrderProcessingWorkflow), |
||||
|
instanceId: order.OrderId, |
||||
|
input: order); |
||||
|
|
||||
|
return Accepted($"/api/orders/{instanceId}", new { instanceId }); |
||||
|
} |
||||
|
|
||||
|
[HttpGet("{instanceId}")] |
||||
|
public async Task<IActionResult> GetStatusAsync(string instanceId) |
||||
|
{ |
||||
|
var state = await _workflowClient.GetWorkflowStateAsync(instanceId); |
||||
|
|
||||
|
if (state is null || !state.Exists) |
||||
|
{ |
||||
|
return NotFound(); |
||||
|
} |
||||
|
|
||||
|
return Ok(new |
||||
|
{ |
||||
|
RuntimeStatus = state.RuntimeStatus.ToString(), |
||||
|
Output = state.ReadOutputAs<OrderResult>() |
||||
|
}); |
||||
|
} |
||||
|
} |
||||
|
``` |
||||
|
|
||||
|
`ScheduleNewWorkflowAsync` returns immediately and the workflow runs in the background, so this fits the asynchronous request pattern nicely: return `202 Accepted` and let the client poll the status endpoint. |
||||
|
|
||||
|
> One ABP-specific thing to keep in mind: ABP enforces antiforgery validation for unsafe HTTP methods on cookie-authenticated requests. Server-to-server or `curl` calls without an auth cookie usually pass straight through, but if you call the `POST` endpoint from a logged-in browser session and get a `400` antiforgery error, you can relax the auto validation for this controller through `AbpAntiForgeryOptions`, the same way the Elsa articles did for the Elsa endpoints. |
||||
|
|
||||
|
## Going Further |
||||
|
|
||||
|
We built a simple linear flow, but **Dapr Workflow** supports the patterns you'll actually need in production, all in plain C#: |
||||
|
|
||||
|
- **Fan-out / fan-in**: schedule many activities in parallel and aggregate the results (it's just `Select` plus `Task.WhenAll`). |
||||
|
- **External events**: pause a workflow until a human approves something or another system calls back. This is great for approval flows. |
||||
|
- **Timers**: durably wait for minutes, days, or months without holding a thread. |
||||
|
- **Child workflows**: break a big process into smaller workflows with their own history and status. |
||||
|
- **Retry policies**: give an activity an exponential backoff policy so transient failures recover on their own. |
||||
|
|
||||
|
## Conclusion |
||||
|
|
||||
|
**Dapr Workflow** gives you durable execution for long-running processes without bolting a heavy orchestration engine into your code. The process is plain C# that reads top to bottom, Dapr makes it fault-tolerant by replaying from the state store, and the orchestration stays deterministic while the side effects live in activities. |
||||
|
|
||||
|
The nice part for us is that none of this fights with ABP. You create a normal ABP solution, add the `Dapr.Workflow` package, register your workflows in a module, and run with `dapr run`. ABP's own Dapr packages still cover pub/sub, service invocation, and locking, so you can mix all of these in the same solution when you need them. |
||||
|
|
||||
|
All the code in this article is self-contained, so you can copy it into a fresh ABP project and follow along from top to bottom. |
||||
|
|
||||
|
Thanks for reading, see you in the next one! |
||||
|
After Width: | Height: | Size: 132 KiB |
|
After Width: | Height: | Size: 35 KiB |
|
After Width: | Height: | Size: 174 KiB |
|
After Width: | Height: | Size: 26 KiB |
|
After Width: | Height: | Size: 8.4 KiB |
@ -0,0 +1,344 @@ |
|||||
|
# Angular 22 State Management: Signals, SignalStore, or NgRx? |
||||
|
|
||||
|
Angular has been steadily moving toward a signal-first architecture since the introduction of Signals in Angular 16. With Angular 22, that transition reaches another milestone. Signals are now at the center of Angular's reactive programming model, while APIs such as Resource and Signal Forms have matured into production-ready solutions. Combined with the framework's continued investment in zoneless change detection, these improvements significantly influence how Angular applications should manage state. |
||||
|
|
||||
|
This shift also changes the role of NgRx. While the classic NgRx Store remains a powerful solution for large, event-driven applications, many scenarios that previously required reducers, selectors, and effects can now be implemented with much simpler, feature-scoped signal stores. Rather than replacing NgRx, Angular 22 encourages developers to choose the right state management strategy based on the scope and complexity of the problem. |
||||
|
|
||||
|
In this article, we'll explore how Angular 22 changes the state management landscape, compare the classic NgRx Store with NgRx SignalStore, and demonstrate best practices for building modern Angular applications. We'll also discuss how Angular's new reactive APIs fit into enterprise applications and what these changes mean for projects built with the ABP Framework. |
||||
|
|
||||
|
## Why Angular 22 Changes State Management |
||||
|
|
||||
|
Angular Signals introduced a fundamentally different approach by providing fine-grained reactivity built directly into the framework. Instead of propagating changes through Observable streams, Signals allow Angular to track exactly which pieces of state are consumed and update only the affected parts of the UI. This results in more predictable rendering, less boilerplate, and improved runtime performance. |
||||
|
|
||||
|
Angular 22 builds on this foundation by making Signals the preferred reactive primitive throughout the framework. New APIs such as **Resource** for asynchronous data loading and **Signal Forms** for reactive forms integrate naturally with Signals, reducing the need for custom RxJS pipelines in many common scenarios. |
||||
|
|
||||
|
For developers using NgRx, this doesn't mean abandoning existing applications or rewriting every store. Instead, it changes how state management should be approached. Component-local state can often be managed with plain Signals, feature-level state fits naturally into SignalStore, and the classic NgRx Store continues to excel for large-scale applications that benefit from centralized event streams, auditing, and global state synchronization. |
||||
|
|
||||
|
Understanding these changing responsibilities is the key to designing maintainable Angular applications in the Angular 22 era. A practical way to think about state management is to start with the simplest solution and introduce additional abstractions only when the application's complexity requires them. |
||||
|
|
||||
|
## Use Signals for Local Component State |
||||
|
|
||||
|
Plain Angular Signals are ideal for state that belongs exclusively to a single component. Examples include dialog visibility, selected tabs, loading indicators, filter values, or temporary form data. |
||||
|
|
||||
|
Signals provide a straightforward API with minimal overhead and integrate seamlessly with Angular's change detection. For state that never needs to be shared outside a component or its immediate children, introducing a dedicated store often adds unnecessary complexity. |
||||
|
|
||||
|
A settings page often contains UI state that doesn't need to be shared with the rest of the application. Using a dedicated store for this would introduce unnecessary complexity. |
||||
|
|
||||
|
```ts |
||||
|
@Component({...}) |
||||
|
export class UserListComponent { |
||||
|
readonly search = signal(''); |
||||
|
readonly showInactive = signal(false); |
||||
|
|
||||
|
readonly filteredUsers = computed(() => |
||||
|
this.users().filter(user => |
||||
|
user.name.includes(this.search()) && |
||||
|
(this.showInactive() || user.active) |
||||
|
) |
||||
|
); |
||||
|
} |
||||
|
``` |
||||
|
|
||||
|
This state is entirely local to the component and doesn't justify introducing a SignalStore. |
||||
|
|
||||
|
## Use NgRx SignalStore for Feature State |
||||
|
|
||||
|
As applications grow, state often needs to be shared across multiple components within the same feature. Examples include user profiles, shopping carts, administration screens, dashboards, or settings pages. |
||||
|
|
||||
|
NgRx SignalStore is designed specifically for these scenarios. It combines Angular Signals with a lightweight, feature-oriented architecture where state, computed values, and business logic are defined together. Instead of scattering logic across reducers, selectors, effects, and services, developers can keep everything related to a feature inside a single store. |
||||
|
|
||||
|
SignalStore also integrates naturally with Angular's signal-based APIs, making it an excellent choice for modern Angular applications built around Resources and Signal Forms. |
||||
|
|
||||
|
A User Management module is shared by multiple pages. The selected user, filters, and loaded entities should remain synchronized across those pages. |
||||
|
|
||||
|
```ts |
||||
|
export const UserStore = signalStore( |
||||
|
withState({ |
||||
|
users: [] as User[], |
||||
|
selectedUserId: null as number | null, |
||||
|
loading: false, |
||||
|
}), |
||||
|
|
||||
|
withComputed(({ users, selectedUserId }) => ({ |
||||
|
selectedUser: computed(() => |
||||
|
users().find(x => x.id === selectedUserId()) |
||||
|
), |
||||
|
})), |
||||
|
|
||||
|
withMethods((store) => ({ |
||||
|
selectUser(id: number) { |
||||
|
patchState(store, { selectedUserId: id }); |
||||
|
}, |
||||
|
})), |
||||
|
); |
||||
|
``` |
||||
|
|
||||
|
Everything related to the feature lives in one place: state, derived values, and business operations. |
||||
|
|
||||
|
## NgRx Store vs. NgRx SignalStore |
||||
|
|
||||
|
Although both solutions belong to the NgRx ecosystem, they are designed to solve different architectural problems. |
||||
|
|
||||
|
The classic NgRx Store follows the Redux pattern, where every state change is represented by an action that flows through reducers before producing a new immutable state. This explicit, event-driven architecture provides excellent traceability and scales well for applications with extensive global interactions. |
||||
|
|
||||
|
SignalStore takes a different approach. Instead of centering the application around dispatched actions, it treats state as a reactive service built with Angular Signals. A SignalStore typically contains three core building blocks: |
||||
|
|
||||
|
- **State**, which represents the application's reactive data. |
||||
|
- **Computed signals**, which derive values from existing state. |
||||
|
- **Methods**, which encapsulate business logic and state updates. |
||||
|
|
||||
|
This functional model significantly reduces boilerplate while remaining predictable and testable. Since it builds directly on Angular Signals, it also integrates naturally with Angular's fine-grained change detection without requiring selectors or `async` pipes for many common scenarios. |
||||
|
|
||||
|
The following comparison summarizes the strengths of each approach. |
||||
|
|
||||
|
|
||||
|
| Feature | Classic NgRx Store | NgRx SignalStore | |
||||
|
| ---------------- | ------------------------------- | --------------------------------- | |
||||
|
| Architecture | Redux-based global store | Feature-oriented reactive store | |
||||
|
| Reactivity | RxJS Observables | Angular Signals | |
||||
|
| Boilerplate | Higher | Lower | |
||||
|
| State Scope | Global application state | Feature or route state | |
||||
|
| Side Effects | Effects | Store methods or `rxMethod` | |
||||
|
| Change Detection | Observable subscriptions | Native signal reactivity | |
||||
|
| Best For | Large event-driven applications | Modern feature-based applications | |
||||
|
|
||||
|
|
||||
|
For most new Angular 22 applications, SignalStore is an excellent default choice for feature-level state management because it embraces the framework's signal-first architecture while keeping code concise and maintainable. The classic NgRx Store remains indispensable for applications that rely heavily on centralized event processing, global synchronization, or advanced debugging capabilities. |
||||
|
|
||||
|
Instead of asking *"Which one should I use?"*, the better question is *"Which scope of state am I trying to manage?"* The answer usually determines the appropriate solution. |
||||
|
|
||||
|
## Angular 22 Features That Improve State Management |
||||
|
|
||||
|
Angular 22 introduces several framework APIs that naturally complement modern state management patterns. Rather than replacing NgRx, these APIs reduce the amount of custom infrastructure developers previously had to build around it. |
||||
|
|
||||
|
### Resource API |
||||
|
|
||||
|
One of the most significant additions is the **Resource API**, which provides a signal-based approach to asynchronous data loading. |
||||
|
|
||||
|
Historically, fetching remote data in Angular involved coordinating `HttpClient`, RxJS operators, subscriptions, loading flags, and error handling. While these patterns remain valid, they often require considerable boilerplate even for straightforward scenarios. |
||||
|
|
||||
|
Resources encapsulate these concerns into a single reactive abstraction. A Resource automatically tracks the signals it depends on, performs requests when those dependencies change, cancels obsolete requests, and exposes its lifecycle through reactive state such as the current value, loading status, and errors. |
||||
|
|
||||
|
This makes Resources particularly well suited for read-oriented operations where data should stay synchronized with application state. |
||||
|
|
||||
|
For example, changing a selected user ID can automatically trigger a new request without manually wiring `switchMap` or managing subscription lifecycles. |
||||
|
|
||||
|
```tsx |
||||
|
const userResource = httpResource(() => ({ |
||||
|
url: `/api/users/${selectedUserId()}` |
||||
|
})); |
||||
|
``` |
||||
|
|
||||
|
### Signal Forms |
||||
|
|
||||
|
Another major improvement is the stabilization of **Signal Forms**. |
||||
|
|
||||
|
Traditional Reactive Forms expose their state through `FormControl` and `FormGroup` instances, requiring developers to query validation status, dirty state, touched state, and values through an imperative API. |
||||
|
|
||||
|
Signal Forms expose these properties as signals instead. Every field becomes reactive by default, making templates easier to read while eliminating much of the manual state synchronization commonly found in form-heavy applications. |
||||
|
|
||||
|
```html |
||||
|
@if (profileForm.email.invalid() && profileForm.email.touched()) { |
||||
|
<span>Please enter a valid email.</span> |
||||
|
} |
||||
|
``` |
||||
|
|
||||
|
Because field state is already reactive, components rarely need additional subscriptions or helper observables to keep the UI synchronized. |
||||
|
|
||||
|
It's important to note that Signal Forms are responsible for **UI state**, while business operations such as saving data, loading entities, or handling server responses still belong in a dedicated service or SignalStore. Keeping these responsibilities separate results in components that remain focused on presentation while stores continue to own application logic. |
||||
|
|
||||
|
## Best Practices for Building Modern SignalStores |
||||
|
|
||||
|
SignalStore significantly reduces the ceremony traditionally associated with state management, but the same architectural principles still apply. A well-designed store should encapsulate business logic without becoming responsible for concerns that belong elsewhere. |
||||
|
|
||||
|
1. Keep Stores Focused on a Single Feature |
||||
|
A SignalStore should represent a cohesive business feature rather than becoming a global container for unrelated state. |
||||
|
For example, an administration module might expose separate stores for users, roles, and permissions instead of combining all administrative functionality into a single, monolithic store. Smaller stores are easier to test, understand, and maintain over time. |
||||
|
2. Store Business State, Not UI State |
||||
|
Not every piece of state belongs in a store. |
||||
|
Transient UI concerns such as dialog visibility, selected tabs, expanded panels, or temporary input values are usually better managed with plain Signals inside the component. |
||||
|
Stores should own state that represents the application's business domain—entities, filters, permissions, settings, or data shared across multiple components. |
||||
|
3. Derive State Instead of Duplicating It |
||||
|
Whenever possible, compute values instead of storing them. |
||||
|
SignalStore's `withComputed()` feature makes it easy to derive reactive values from existing state, reducing the likelihood of inconsistent or stale data. |
||||
|
Instead of storing both a list of users and an active user count, derive the count directly from the collection. |
||||
|
```tsx |
||||
|
withComputed(({ users }) => ({ |
||||
|
activeUsers: computed(() => |
||||
|
users().filter(user => user.active).length |
||||
|
), |
||||
|
})) |
||||
|
``` |
||||
|
Keeping a single source of truth simplifies updates and reduces maintenance. |
||||
|
4. Prefer Immutable State Updates |
||||
|
Although SignalStore simplifies updates through `patchState()`, state should still be treated as immutable. |
||||
|
Updating only the affected portions of state makes changes predictable and allows Angular's signal system to efficiently notify dependent computations. |
||||
|
```tsx |
||||
|
patchState(store, { |
||||
|
users: [...store.users(), newUser] |
||||
|
}); |
||||
|
``` |
||||
|
|
||||
|
## Integrating Resources with SignalStore |
||||
|
|
||||
|
Resources and SignalStore solve different problems, and understanding their responsibilities leads to a cleaner architecture. |
||||
|
|
||||
|
A **Resource** is responsible for synchronizing data with a remote source. It knows how to load data, react to parameter changes, expose loading and error states, and keep requests up to date. |
||||
|
|
||||
|
A **SignalStore**, on the other hand, owns the application's business state. It coordinates operations, exposes domain-specific methods, derives computed values, and serves as the single source of truth for a feature. |
||||
|
|
||||
|
Rather than replacing one another, they work best together. |
||||
|
|
||||
|
A common pattern is to use a Resource for loading entities while allowing the store to expose business operations that modify those entities. |
||||
|
|
||||
|
```tsx |
||||
|
export const UserStore = signalStore( |
||||
|
withState({ |
||||
|
selectedUserId: undefined as number | undefined, |
||||
|
}), |
||||
|
|
||||
|
withComputed(({ selectedUserId }) => ({ |
||||
|
userResource: httpResource<User>(() => { |
||||
|
const id = selectedUserId(); |
||||
|
|
||||
|
return id |
||||
|
? { |
||||
|
url: `/api/users/${id}`, |
||||
|
} |
||||
|
: undefined; |
||||
|
}), |
||||
|
})), |
||||
|
|
||||
|
withMethods((store) => ({ |
||||
|
selectUser(id: number) { |
||||
|
patchState(store, { |
||||
|
selectedUserId: id, |
||||
|
}); |
||||
|
}, |
||||
|
})), |
||||
|
); |
||||
|
``` |
||||
|
|
||||
|
In this example, changing the selected user automatically causes the Resource to fetch new data. The store doesn't need to manage subscriptions or manually coordinate loading indicators because the Resource already exposes this information through signals. |
||||
|
|
||||
|
This separation keeps data synchronization declarative while allowing the store to remain focused on business behavior. |
||||
|
|
||||
|
## Integrating Signal Forms with SignalStore |
||||
|
|
||||
|
Signal Forms and SignalStore naturally complement one another because both are built on Angular Signals. However, they should not be treated as interchangeable. |
||||
|
|
||||
|
Signal Forms are responsible for managing user input and validation, while SignalStore coordinates business operations such as loading, updating, and persisting data. |
||||
|
|
||||
|
A common workflow consists of four steps: |
||||
|
|
||||
|
1. Load the entity through the store. |
||||
|
2. Populate the Signal Form. |
||||
|
3. Allow the user to edit the data. |
||||
|
4. Submit the updated values back to the store. |
||||
|
|
||||
|
The component remains responsible only for orchestrating the interaction between the form and the store. |
||||
|
|
||||
|
```tsx |
||||
|
@Component({ |
||||
|
// ... |
||||
|
}) |
||||
|
export class UserEditorComponent { |
||||
|
readonly store = inject(UserStore); |
||||
|
|
||||
|
readonly form = form({ |
||||
|
name: '', |
||||
|
email: '', |
||||
|
}); |
||||
|
|
||||
|
async save() { |
||||
|
if (this.form.invalid()) { |
||||
|
return; |
||||
|
} |
||||
|
|
||||
|
await this.store.updateUser(this.form.value()); |
||||
|
} |
||||
|
} |
||||
|
``` |
||||
|
|
||||
|
This approach keeps presentation concerns inside the component while allowing business rules to remain centralized in the store. |
||||
|
|
||||
|
## Handling Asynchronous Operations |
||||
|
|
||||
|
One challenge when combining Signal Forms with SignalStore is coordinating asynchronous operations. |
||||
|
|
||||
|
A form submission typically expects an asynchronous operation to complete before updating its own state. Meanwhile, the store is responsible for managing loading indicators, server errors, and successful updates. |
||||
|
|
||||
|
Instead of placing HTTP requests directly inside components, expose descriptive methods such as `createUser()`, `updateProfile()`, or `changePassword()` from the store. Components simply invoke these methods and react to the outcome. |
||||
|
|
||||
|
This keeps components lightweight while making business logic reusable across multiple views. |
||||
|
|
||||
|
## A Clear Separation of Responsibilities |
||||
|
|
||||
|
A useful guideline is to divide responsibilities as follows: |
||||
|
|
||||
|
|
||||
|
| Concern | Recommended Owner | |
||||
|
| ------------------- | ------------------------------------------ | |
||||
|
| User input | Signal Forms | |
||||
|
| Validation | Signal Forms | |
||||
|
| Loading remote data | Resource | |
||||
|
| Business rules | SignalStore | |
||||
|
| State mutations | SignalStore | |
||||
|
| HTTP persistence | Service or repository invoked by the store | |
||||
|
|
||||
|
|
||||
|
Following these boundaries results in components that focus on presentation, stores that encapsulate business logic, and Resources that handle server synchronization. Each part has a single responsibility, making the application easier to understand, test, and maintain as it grows. |
||||
|
|
||||
|
## Migrating from Classic NgRx to SignalStore |
||||
|
|
||||
|
Migrating to SignalStore doesn't require replacing an entire application's state management strategy overnight. In fact, most enterprise applications can adopt SignalStore incrementally while continuing to use the classic NgRx Store where it provides the greatest value. |
||||
|
|
||||
|
A practical migration strategy is to start with isolated features rather than the application's global state. |
||||
|
|
||||
|
### Keep the Classic Store for Global State |
||||
|
|
||||
|
Global concerns such as authentication, user sessions, application configuration, notifications, and cross-feature communication often continue to benefit from the centralized architecture of the classic NgRx Store. |
||||
|
|
||||
|
These areas typically rely on dispatched actions and event-driven workflows that remain well suited to Redux patterns. |
||||
|
|
||||
|
### Introduce SignalStore for New Features |
||||
|
|
||||
|
New feature modules are excellent candidates for SignalStore. |
||||
|
|
||||
|
Instead of creating actions, reducers, selectors, and effects, developers can define state, computed values, and business methods in a single store. This reduces boilerplate while aligning the feature with Angular's signal-first architecture. |
||||
|
|
||||
|
Existing features can also be migrated gradually as they evolve, avoiding large-scale refactoring efforts. |
||||
|
|
||||
|
### Move Component State First |
||||
|
|
||||
|
The easiest migration is often replacing component-local Observables and `BehaviorSubject`s with Signals. |
||||
|
|
||||
|
Many components don't require a dedicated store at all. Converting temporary UI state to Signals simplifies the codebase immediately and familiarizes teams with Angular's reactive model before introducing SignalStore. |
||||
|
|
||||
|
Incremental adoption minimizes risk while allowing teams to modernize applications at a sustainable pace. |
||||
|
|
||||
|
## What This Means for ABP Applications |
||||
|
|
||||
|
Angular 22's signal-first architecture aligns well with ABP's modular application model. |
||||
|
|
||||
|
Most ABP applications consist of independent feature modules such as Identity, Tenant Management, SaaS, or CMS. These modules naturally map to feature-scoped SignalStores, allowing state and business logic to remain encapsulated within each module. However, the full support will be introduced in the next version. |
||||
|
|
||||
|
As Angular continues investing in Signals, Resources, and Signal Forms, future ABP applications can increasingly rely on the framework's native reactive APIs instead of custom state management patterns. |
||||
|
|
||||
|
This doesn't diminish the importance of RxJS or the classic NgRx Store. RxJS remains an essential foundation of Angular's HTTP infrastructure and many third-party libraries, while the traditional Store continues to provide an excellent solution for complex global state management. |
||||
|
|
||||
|
Instead, Angular 22 encourages developers to use each reactive tool where it provides the greatest value. |
||||
|
|
||||
|
Whether you're upgrading an existing ABP application or starting a new project, adopting SignalStore for feature-level state can simplify development while remaining fully compatible with Angular's evolving ecosystem. |
||||
|
|
||||
|
## Conclusion |
||||
|
|
||||
|
Angular's evolution toward a signal-first architecture represents more than a new reactive API—it changes how applications should be designed. |
||||
|
|
||||
|
Rather than treating every piece of state as part of a centralized store, Angular now encourages developers to choose the appropriate abstraction for each responsibility. Plain Signals excel at local component state, SignalStore provides a lightweight solution for feature-level business logic, Resources simplify server synchronization, and Signal Forms modernize user input management. |
||||
|
|
||||
|
The classic NgRx Store continues to play an important role in large, event-driven applications, but it no longer needs to be the default choice for every state management scenario. |
||||
|
|
||||
|
By embracing these complementary tools, developers can build Angular applications that are simpler to maintain, require less boilerplate, and integrate naturally with the framework's latest capabilities. |
||||
|
|
||||
|
As Angular continues to evolve around Signals and fine-grained reactivity, adopting these patterns today will help applications remain aligned with the framework's direction while providing a solid foundation for future improvements. |
||||
@ -0,0 +1,55 @@ |
|||||
|
```json |
||||
|
//[doc-seo] |
||||
|
{ |
||||
|
"Description": "Compare Modern and Classic ABP Studio templates, including architecture mapping, UI choices, mobile options, and when to choose each template family." |
||||
|
} |
||||
|
``` |
||||
|
|
||||
|
# Modern vs Classic Templates |
||||
|
|
||||
|
ABP Studio provides two solution template families: **Modern** and **Classic**. Both families create production-ready ABP solutions and share the same ABP backend concepts, such as Entity Framework Core and MongoDB database options, OpenIddict authentication, multi-tenancy, optional modules, test projects, language selection and deployment-related configuration where they are supported. |
||||
|
|
||||
|
The main difference is how you choose and shape the solution. **Classic templates** are the traditional template-first flow. You first choose a concrete template, such as Single-Layer, Layered or Microservice, and then select UI, database, mobile and module options. **Modern templates** are the newer architecture-first flow. You first choose the backend architecture, then ABP Studio maps your selection to the proper modern template. |
||||
|
|
||||
|
## Template Families |
||||
|
|
||||
|
| Template family | Template names | Main idea | |
||||
|
| --- | --- | --- | |
||||
|
| Classic | `app-nolayers`, `app`, `microservice` | The traditional ABP Studio solution templates with the broadest UI framework choices. | |
||||
|
| Modern | `app-nolayers-modern`, `app-modern`, `microservice-modern` | The newer ABP Studio templates focused on React-based web applications and an architecture-first creation flow. | |
||||
|
|
||||
|
## Modern Architecture Mapping |
||||
|
|
||||
|
When you use the Modern solution creation flow in ABP Studio, your selected architecture maps to a modern template: |
||||
|
|
||||
|
| Modern architecture | Generated template | Notes | |
||||
|
| --- | --- | --- | |
||||
|
| Simple Monolith | `app-nolayers-modern` | A simpler application structure with the main backend code in one host project. | |
||||
|
| Layered Monolith | `app-modern` | A layered solution based on Domain Driven Design practices. | |
||||
|
| Modular Monolith | `app-nolayers-modern` | Uses the modern single-layer template with modular solution options enabled. | |
||||
|
| Microservice | `microservice-modern` | A distributed solution with dedicated services, gateways and applications. | |
||||
|
|
||||
|
## Practical Differences |
||||
|
|
||||
|
| Area | Classic templates | Modern templates | |
||||
|
| --- | --- | --- | |
||||
|
| Creation flow | Template-first: select Single-Layer, Layered or Microservice first. | Architecture-first: select Simple Monolith, Layered Monolith, Modular Monolith or Microservice first. | |
||||
|
| Web UI choices | Supports MVC / Razor Pages, Angular, Blazor WebAssembly, Blazor Server, Blazor Web App, MAUI Blazor and No UI depending on the selected template. | Supports React or No UI. | |
||||
|
| Mobile choices | Keeps broader mobile choices, including MAUI and React Native in templates that support mobile applications. | Supports React Native or no mobile application. | |
||||
|
| Public website | Uses the classic public website structure where the selected template supports it. | Uses React-based public web assets where the selected modern template supports a public website. | |
||||
|
| Frontend assets | Uses the established ABP UI framework integrations and theme options for MVC, Angular and Blazor applications. | Uses newer React and `shadcn`-oriented frontend assets. | |
||||
|
| Best fit | Existing projects, teams using MVC / Angular / Blazor / MAUI, and scenarios that need the broadest UI framework choices. | New React-focused solutions and teams that prefer the newer Studio creation experience. | |
||||
|
|
||||
|
## Which One Should I Choose? |
||||
|
|
||||
|
Choose **Modern** if you are starting a new solution with React UI, want a React Native mobile application, prefer the newer architecture-first ABP Studio flow, or plan to use AI-assisted programming for an AI-driven project. |
||||
|
|
||||
|
Choose **Classic** if you want MVC / Razor Pages, Angular, Blazor, MAUI Blazor or MAUI mobile options, or if your team is following existing Classic-template tutorials, conventions or project structure. |
||||
|
|
||||
|
ABP Studio may show or hide some templates and options based on your license. For example, Microservice templates require a higher license level than regular application templates, and Modern application templates are not shown in the Community Edition. |
||||
|
|
||||
|
## See Also |
||||
|
|
||||
|
* [Solution Template Selection Guide](guide.md) |
||||
|
* [Startup Solution Templates](index.md) |
||||
|
* [Get Started](../get-started/index.md) |
||||
@ -1 +1 @@ |
|||||
{"version":3,"sourceRoot":"","sources":["vs.scss"],"names":[],"mappings":"AAGA;EACI;EACA;;AAEA;EACI;EACA;;AAIJ;EACI;;AAGJ;EACI;EACA;;AAGJ;EACI;;AAGJ;EACI;;AAGJ;EACI;EACA;EACA;;AAIA;EACI;;AAGJ;AAAA;AAAA;AAAA;EAII;;AAIR;AAAA;EAEI;;AAGJ;EACI;;AAEA;EACI;;AAEJ;EACI;;AAIR;AAAA;EAEI;EACA;EACA;;AAGJ;EACI;;AAEA;EACI;EACA;EACA;EACA;EACA;;AAEA;EACI;;;AAMhB;EACI;;AAEA;EACI;EACA;EACA,KA9FK;EA+FL,QA/FK;EAgGL;EACA;EACA;EACA;EACA;EACA;EACA;;AAIQ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;EACA;;AAIR;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;EACA;;AAMhB;EACI;;AAEA;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;;AAGJ;EACI;EACA;;AAEJ;EACI;;AAEA;EACI;EACA;;AAGJ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAIR;AAAA;EAEI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;AAAA;AAAA;AAAA;AAAA;EAII;;AAIR;EACI;EACA;;AAEJ;EACI;EACA;;AAEA;EACI;;AAIR;EACI;;AAEA;EAII;;AAIR;EACI;EACA;EACA;;AAIR;EACI;;AAIR;EAEI;EACA;;AAEA;EACI;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;;AAKZ;EACI;EACA;EACA;EACA;EACA;;AAGJ;EACI;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAGJ;EACI;EACA;;AAIR;EACI;EACA;EACA;EACA;EACA;;AAGJ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAGI;EACI;;AAIR;EACI;;AAIR;EACI;;AAGI;EACI;;AAGJ;EACI;;AAGI;EACI;;AAQhB;EACI;EACA;;AAIA;EACI;EACA;;AAMA;EACI;;AAOpB;EACI;;AAKhB;EACI;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAGJ;EACI;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;;AACA;EACI;EACA;EACA;EACA;EACA;;AAMA;EACI;EACA;EACA;EACA;EACA;;AACA;EACI;;AAEJ;EACI;EACA;;AAMhB;EACI;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAEJ;EACI;;AAGJ;EACI;EACA;;AAKZ;EACI;EACA;;AAEA;EACI;;AAEA;EACI;;AAGJ;EACI;EACA;;AAIR;EACI;EACA;EACA;;AAEA;EACI;;AAGJ;EACI;EACA;EACA;EACA;;AAGJ;EACI;EACA;EACA;EACA;EACA;EACA;;AAKJ;EACI;EACA;EACA;;AAGJ;EACI;;AAEA;EACI;EACA;EACA;EACA;EACA;EACA;EACA;;AAMA;EACI;;AAQhB;EACI;;AAGJ;EACI;EACA;;AAEA;EACI;EACA;EACA;;AAGJ;EACI;EACA;EACA;;AAGJ;AAAA;AAAA;AAAA;EAII;EACA;EACA;;AAGJ;AAAA;AAAA;AAAA;AAAA;AAAA;EAMI;EACA;;AAEA;AAAA;AAAA;AAAA;AAAA;AAAA;EACI;EACA;EACA;EACA;EACA;EACA;EACA;;AAIA;AAAA;AAAA;AAAA;AAAA;AAAA;EACI;;AAKZ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;;AAGJ;EACI;EACA;EACA;EACA;EACA;;AAGJ;EACI;EACA;EACA;;AAGI;EACI;;AAIR;EACI;;AAGJ;AAAA;EAEI;EACA;;AAGJ;EACI;EACA;;AAGJ;EACI;;AAGJ;EACI;;AAKZ;EACI;EACA;EACA;EACA;;AACA;EACI;EACA;EACA;EACA;EACA;;AAEJ;EACI;EACA;EACA;EACA;;AACA;EACI;;AAKZ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAMR;EACI;EACA;;AAEA;EACI;;AAIR;EACI;EACA;EACA;;AAKZ;EACI;EACA;;AAEA;EACI;EACA;EACA,KAtsBC;EAusBD;EACA;EACA;;AAGI;EACI;EACA;EACA;;AAEA;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;EACA;;AAMA;EACI;;AAMA;EACI;;AAQxB;EACI;;AAIR;EACI;;AAGJ;EACI;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAIR;EACI;EACA;EACA;EACA;EACA,eAlxBC;EAmxBD;;AAEA;EACI;EACA;EACA;;AACA;EACI;;AAGR;EACI;EACA,SAhyBH;;AAkyBD;EACI;EACA;EACA;;AAGJ;EACI;;;AAMhB;EACI;IACI;;EAEA;IACI;;EAGJ;IACI;;EAGJ;AAAA;IAEI;IACA;IACA;IACA;IACA;IACA;IACA;;EAQR;IACI;;EAEA;IACI;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;;EAGI;IACI;IACA;IACA;IACA;;EAEA;IACI;IACA;IACA;IACA;IACA;IACA;IACA;IACA;;EAEA;IACI;;EAIR;IACI;;EAGJ;IACI;IACA;;EAGJ;IACI;IACA;IACA;IACA;IACA;IACA;IACA;IACA;;EAEA;IACI;IACA;IACA;;EAEA;IACI;;EAKZ;IACI;IACA;IACA;IACA;IACA;IACA;IACA;IACA;;EAIR;IACI;IACA;IACA;;EAIR;IACI;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;;EAEA;IACI;;EAMZ;IACI;IACA;IACA;IACA;IACA;;EAEA;IACI;;EAGJ;IACI;;EAIA;IACI;;EAEJ;IACI;;EAGJ;IACI;IACA;IACA;IACA;;EAGJ;IACI;IACA;IACA;IACA;;EAKZ;IACI;IACA;IACA;;EAEA;IACI;IACA;;EAIR;IACI;;EAEA;IACI;;;AAMhB;EAIgB;IACI;;EAEJ;IACI;;EAMI;IACI;IACA;;;AAS5B;EAEQ;IACI;IACA;;EAEJ;IAII;;EAHA;IACI;;;AAOhB;EAEQ;IACI;IACA;IACA;IACA;;EAEA;IACI;IACA;IACA","file":"vs.css"} |
{"version":3,"sourceRoot":"","sources":["vs.scss"],"names":[],"mappings":"AAGA;EACI;EACA;;AAEA;EACI;EACA;;AAIJ;EACI;;AAGJ;EACI;EACA;;AAGJ;EACI;;AAGJ;EACI;;AAGJ;EACI;EACA;EACA;;AAIA;EACI;;AAGJ;AAAA;AAAA;AAAA;EAII;;AAIR;AAAA;EAEI;;AAGJ;EACI;;AAEA;EACI;;AAEJ;EACI;;AAIR;AAAA;EAEI;EACA;EACA;;AAGJ;EACI;;AAKA;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAGA;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAGJ;EAEI;EACA;;AAIJ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAGJ;EAEI;EACA;EACA;EACA;EACA;;AAIJ;EACI;;AAGJ;EACI;EACA;EACA;;AAGJ;EACI;EACA;EACA;EACA;;AAEA;EACI;;AAIR;EACI;EACA;EACA;EACA;;AAEA;EACI;;AAIR;EA5GJ;IA6GQ;IACA;IACA;;EAEA;IACI;IACA;IACA;IACA;IACA;;EAGJ;IACI;IACA;IACA;IACA;;;AAOR;EAEI;;AAGJ;EACI;IAEI;;;;AAOpB;EACI;;AAEA;EACI;EACA;EACA,KAtOK;EAuOL,QAvOK;EAwOL;EACA;EACA;EACA;EACA;EACA;EACA;;AAIQ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;EACA;;AAIR;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;EACA;;AAMhB;EACI;;AAEA;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;;AAGJ;EACI;EACA;;AAEJ;EACI;;AAEA;EACI;EACA;;AAGJ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAIR;AAAA;EAEI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;AAAA;AAAA;AAAA;AAAA;EAII;;AAIR;EACI;EACA;;AAEJ;EACI;EACA;;AAEA;EACI;;AAIR;EACI;;AAEA;EAII;;AAIR;EACI;EACA;EACA;;AAIR;EACI;;AAIR;EAEI;EACA;;AAEA;EACI;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;;AAKZ;EACI;EACA;EACA;EACA;EACA;;AAGJ;EACI;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAGJ;EACI;EACA;;AAIR;EACI;EACA;EACA;EACA;EACA;;AAGJ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAGI;EACI;;AAIR;EACI;;AAIR;EACI;;AAGI;EACI;;AAGJ;EACI;;AAGI;EACI;;AAQhB;EACI;EACA;;AAIA;EACI;EACA;;AAMA;EACI;;AAOpB;EACI;;AAKhB;EACI;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAGJ;EACI;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;;AACA;EACI;EACA;EACA;EACA;EACA;;AAMA;EACI;EACA;EACA;EACA;EACA;;AACA;EACI;;AAEJ;EACI;EACA;;AAMhB;EACI;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAEJ;EACI;;AAGJ;EACI;EACA;;AAKZ;EACI;EACA;;AAEA;EACI;;AAEA;EACI;;AAGJ;EACI;EACA;;AAIR;EACI;EACA;EACA;;AAEA;EACI;;AAGJ;EACI;EACA;EACA;EACA;;AAGJ;EACI;EACA;EACA;EACA;EACA;EACA;;AAKJ;EACI;EACA;EACA;;AAGJ;EACI;;AAEA;EACI;EACA;EACA;EACA;EACA;EACA;EACA;;AAMA;EACI;;AAQhB;EACI;;AAGJ;EACI;EACA;;AAEA;EACI;EACA;EACA;;AAGJ;EACI;EACA;EACA;;AAGJ;AAAA;AAAA;AAAA;EAII;EACA;EACA;;AAGJ;AAAA;AAAA;AAAA;AAAA;AAAA;EAMI;EACA;;AAEA;AAAA;AAAA;AAAA;AAAA;AAAA;EACI;EACA;EACA;EACA;EACA;EACA;EACA;;AAIA;AAAA;AAAA;AAAA;AAAA;AAAA;EACI;;AAKZ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;;AAGJ;EACI;EACA;EACA;EACA;EACA;;AAGJ;EACI;EACA;EACA;;AAGI;EACI;;AAIR;EACI;;AAGJ;AAAA;EAEI;EACA;;AAGJ;EACI;EACA;;AAGJ;EACI;;AAGJ;EACI;;AAKZ;EACI;EACA;EACA;EACA;;AACA;EACI;EACA;EACA;EACA;EACA;;AAEJ;EACI;EACA;EACA;EACA;;AACA;EACI;;AAKZ;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAMR;EACI;EACA;;AAEA;EACI;;AAIR;EACI;EACA;EACA;;AAKZ;EACI;EACA;;AAEA;EACI;EACA;EACA,KA90BC;EA+0BD;EACA;EACA;;AAGI;EACI;EACA;EACA;;AAEA;EACI;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;EACA;;AAEA;EACI;EACA;EACA;EACA;;AAMA;EACI;;AAMA;EACI;;AAQxB;EACI;;AAIR;EACI;;AAGJ;EACI;EACA;EACA;EACA;EACA;;AAEA;EACI;;AAIR;EACI;EACA;EACA;EACA;EACA,eA15BC;EA25BD;;AAEA;EACI;EACA;EACA;;AACA;EACI;;AAGR;EACI;EACA,SAx6BH;;AA06BD;EACI;EACA;EACA;;AAGJ;EACI;;;AAMhB;EACI;IACI;;EAEA;IACI;;EAGJ;IACI;;EAGJ;AAAA;IAEI;IACA;IACA;IACA;IACA;IACA;IACA;;EAQR;IACI;;EAEA;IACI;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;;EAGI;IACI;IACA;IACA;IACA;;EAEA;IACI;IACA;IACA;IACA;IACA;IACA;IACA;IACA;;EAEA;IACI;;EAIR;IACI;;EAGJ;IACI;IACA;;EAGJ;IACI;IACA;IACA;IACA;IACA;IACA;IACA;IACA;;EAEA;IACI;IACA;IACA;;EAEA;IACI;;EAKZ;IACI;IACA;IACA;IACA;IACA;IACA;IACA;IACA;;EAIR;IACI;IACA;IACA;;EAIR;IACI;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;IACA;;EAEA;IACI;;EAMZ;IACI;IACA;IACA;IACA;IACA;;EAEA;IACI;;EAGJ;IACI;;EAIA;IACI;;EAEJ;IACI;;EAGJ;IACI;IACA;IACA;IACA;;EAGJ;IACI;IACA;IACA;IACA;;EAKZ;IACI;IACA;IACA;;EAEA;IACI;IACA;;EAIR;IACI;;EAEA;IACI;;;AAMhB;EAIgB;IACI;;EAEJ;IACI;;EAMI;IACI;IACA;;;AAS5B;EAEQ;IACI;IACA;;EAEJ;IAII;;EAHA;IACI;;;AAOhB;EAEQ;IACI;IACA;IACA;IACA;;EAEA;IACI;IACA;IACA","file":"vs.css"} |
||||
@ -0,0 +1,48 @@ |
|||||
|
using System.Linq; |
||||
|
using Microsoft.AspNetCore.Identity; |
||||
|
using Volo.Abp.Security.Claims; |
||||
|
|
||||
|
namespace Volo.Abp.OpenIddict; |
||||
|
|
||||
|
public static class AbpOpenIddictSecurityStampValidatorOptionsExtensions |
||||
|
{ |
||||
|
public static SecurityStampValidatorOptions RemoveClientIdClaim(this SecurityStampValidatorOptions options) |
||||
|
{ |
||||
|
// OpenIddictClaimsPrincipalContributor stamps the ambient /connect/authorize request's client_id
|
||||
|
// onto every principal built by CreateUserPrincipalAsync. That is meant for the access_token, but the
|
||||
|
// cookie security-stamp validator rebuilds the interactive cookie through the same method, so a refresh
|
||||
|
// that lands on /connect/authorize leaks client_id into the cookie and corrupts ICurrentClient.
|
||||
|
// OnRefreshingPrincipal is the only place the cookie is re-written and never runs for token issuance.
|
||||
|
var previousOnRefreshingPrincipal = options.OnRefreshingPrincipal; |
||||
|
options.OnRefreshingPrincipal = async context => |
||||
|
{ |
||||
|
// Run the previous callback first: ABP Identity's UpdatePrincipal copies claims that are on the
|
||||
|
// current cookie but not on the new principal forward, re-introducing client_id from an
|
||||
|
// already-corrupted cookie. Removing it afterwards lets such a cookie self-heal on its next refresh.
|
||||
|
if (previousOnRefreshingPrincipal != null) |
||||
|
{ |
||||
|
await previousOnRefreshingPrincipal.Invoke(context); |
||||
|
} |
||||
|
|
||||
|
RemoveClientIdClaimsFromPrincipal(context); |
||||
|
}; |
||||
|
|
||||
|
return options; |
||||
|
} |
||||
|
|
||||
|
private static void RemoveClientIdClaimsFromPrincipal(SecurityStampRefreshingPrincipalContext context) |
||||
|
{ |
||||
|
if (context.NewPrincipal == null) |
||||
|
{ |
||||
|
return; |
||||
|
} |
||||
|
|
||||
|
foreach (var identity in context.NewPrincipal.Identities) |
||||
|
{ |
||||
|
foreach (var claim in identity.FindAll(AbpClaimTypes.ClientId).ToArray()) |
||||
|
{ |
||||
|
identity.RemoveClaim(claim); |
||||
|
} |
||||
|
} |
||||
|
} |
||||
|
} |
||||
@ -0,0 +1,21 @@ |
|||||
|
<Project Sdk="Microsoft.NET.Sdk"> |
||||
|
|
||||
|
<Import Project="..\..\..\..\common.props" /> |
||||
|
|
||||
|
<PropertyGroup> |
||||
|
<TargetFramework>net10.0</TargetFramework> |
||||
|
<RootNamespace /> |
||||
|
</PropertyGroup> |
||||
|
|
||||
|
<ItemGroup> |
||||
|
<PackageReference Include="Microsoft.NET.Test.Sdk" /> |
||||
|
<PackageReference Include="xunit" /> |
||||
|
<PackageReference Include="xunit.runner.visualstudio" /> |
||||
|
<PackageReference Include="Shouldly" /> |
||||
|
</ItemGroup> |
||||
|
|
||||
|
<ItemGroup> |
||||
|
<ProjectReference Include="..\..\src\Volo.Abp.OpenIddict.AspNetCore\Volo.Abp.OpenIddict.AspNetCore.csproj" /> |
||||
|
</ItemGroup> |
||||
|
|
||||
|
</Project> |
||||
@ -0,0 +1,154 @@ |
|||||
|
using System; |
||||
|
using System.Linq; |
||||
|
using System.Security.Claims; |
||||
|
using System.Threading.Tasks; |
||||
|
using Microsoft.AspNetCore.Identity; |
||||
|
using Shouldly; |
||||
|
using Volo.Abp.Security.Claims; |
||||
|
using Xunit; |
||||
|
|
||||
|
namespace Volo.Abp.OpenIddict; |
||||
|
|
||||
|
public class AbpOpenIddictSecurityStampValidatorOptionsExtensions_Tests |
||||
|
{ |
||||
|
[Fact] |
||||
|
public async Task Should_Remove_ClientId_From_Refreshed_Principal() |
||||
|
{ |
||||
|
var context = new SecurityStampRefreshingPrincipalContext |
||||
|
{ |
||||
|
NewPrincipal = CreateCookiePrincipal( |
||||
|
new Claim(AbpClaimTypes.UserId, "user-1"), |
||||
|
new Claim(AbpClaimTypes.ClientId, "MyClient")) |
||||
|
}; |
||||
|
|
||||
|
await RefreshPrincipalAsync(context); |
||||
|
|
||||
|
context.NewPrincipal.FindAll(AbpClaimTypes.ClientId).ShouldBeEmpty(); |
||||
|
context.NewPrincipal.FindFirst(AbpClaimTypes.UserId).Value.ShouldBe("user-1"); |
||||
|
} |
||||
|
|
||||
|
[Fact] |
||||
|
public async Task Should_Not_Touch_A_Principal_Without_ClientId() |
||||
|
{ |
||||
|
var context = new SecurityStampRefreshingPrincipalContext |
||||
|
{ |
||||
|
NewPrincipal = CreateCookiePrincipal(new Claim(AbpClaimTypes.UserId, "user-1")) |
||||
|
}; |
||||
|
|
||||
|
await RefreshPrincipalAsync(context); |
||||
|
|
||||
|
context.NewPrincipal.Claims.Count().ShouldBe(1); |
||||
|
context.NewPrincipal.FindFirst(AbpClaimTypes.UserId).Value.ShouldBe("user-1"); |
||||
|
} |
||||
|
|
||||
|
[Fact] |
||||
|
public async Task Should_Remove_Every_ClientId_Claim_From_Every_Identity() |
||||
|
{ |
||||
|
var principal = new ClaimsPrincipal(); |
||||
|
principal.AddIdentity(new ClaimsIdentity( |
||||
|
new[] { new Claim(AbpClaimTypes.UserId, "user-1"), new Claim(AbpClaimTypes.ClientId, "Client-A") }, |
||||
|
IdentityConstants.ApplicationScheme)); |
||||
|
principal.AddIdentity(new ClaimsIdentity( |
||||
|
new[] { new Claim(AbpClaimTypes.ClientId, "Client-B"), new Claim(AbpClaimTypes.ClientId, "Client-C") }, |
||||
|
IdentityConstants.ApplicationScheme)); |
||||
|
|
||||
|
var context = new SecurityStampRefreshingPrincipalContext { NewPrincipal = principal }; |
||||
|
|
||||
|
await RefreshPrincipalAsync(context); |
||||
|
|
||||
|
context.NewPrincipal.FindAll(AbpClaimTypes.ClientId).ShouldBeEmpty(); |
||||
|
context.NewPrincipal.FindFirst(AbpClaimTypes.UserId).Value.ShouldBe("user-1"); |
||||
|
} |
||||
|
|
||||
|
[Fact] |
||||
|
public async Task Should_Not_Throw_When_New_Principal_Is_Null() |
||||
|
{ |
||||
|
var context = new SecurityStampRefreshingPrincipalContext { NewPrincipal = null }; |
||||
|
|
||||
|
await Should.NotThrowAsync(() => RefreshPrincipalAsync(context)); |
||||
|
} |
||||
|
|
||||
|
[Fact] |
||||
|
public async Task Should_Remove_ClientId_After_Running_The_Previously_Registered_Callback() |
||||
|
{ |
||||
|
// The real module order: ABP Identity's callback is registered first, the removal after it. Identity's
|
||||
|
// SecurityStampValidatorCallback.UpdatePrincipal copies client_id from an already-corrupted cookie onto
|
||||
|
// the refreshed principal; the removal still strips it, so the cookie self-heals on its next refresh.
|
||||
|
var previousCallbackRan = false; |
||||
|
Task PreviousCallback(SecurityStampRefreshingPrincipalContext context) |
||||
|
{ |
||||
|
previousCallbackRan = true; |
||||
|
CopyClientIdForward(context); |
||||
|
return Task.CompletedTask; |
||||
|
} |
||||
|
|
||||
|
var refreshingContext = CreateCorruptedCookieRefreshContext(); |
||||
|
|
||||
|
await RefreshPrincipalAsync(refreshingContext, PreviousCallback); |
||||
|
|
||||
|
previousCallbackRan.ShouldBeTrue(); |
||||
|
refreshingContext.NewPrincipal.FindAll(AbpClaimTypes.ClientId).ShouldBeEmpty(); |
||||
|
} |
||||
|
|
||||
|
[Fact] |
||||
|
public async Task Should_Remove_ClientId_When_A_Callback_Is_Registered_After_It() |
||||
|
{ |
||||
|
// The reverse order: the removal is registered first and an Identity-style callback (which runs its own
|
||||
|
// copy-forward before invoking the previous callback) is registered after it. Because the two wrappers
|
||||
|
// chain in opposite directions, the removal still runs last, so the order the modules load does not matter.
|
||||
|
var options = new SecurityStampValidatorOptions(); |
||||
|
options.RemoveClientIdClaim(); |
||||
|
|
||||
|
var previousOnRefreshingPrincipal = options.OnRefreshingPrincipal; |
||||
|
options.OnRefreshingPrincipal = async context => |
||||
|
{ |
||||
|
CopyClientIdForward(context); |
||||
|
if (previousOnRefreshingPrincipal != null) |
||||
|
{ |
||||
|
await previousOnRefreshingPrincipal.Invoke(context); |
||||
|
} |
||||
|
}; |
||||
|
|
||||
|
var refreshingContext = CreateCorruptedCookieRefreshContext(); |
||||
|
|
||||
|
await options.OnRefreshingPrincipal(refreshingContext); |
||||
|
|
||||
|
refreshingContext.NewPrincipal.FindAll(AbpClaimTypes.ClientId).ShouldBeEmpty(); |
||||
|
} |
||||
|
|
||||
|
private static async Task RefreshPrincipalAsync( |
||||
|
SecurityStampRefreshingPrincipalContext context, |
||||
|
Func<SecurityStampRefreshingPrincipalContext, Task> previousCallback = null) |
||||
|
{ |
||||
|
var options = new SecurityStampValidatorOptions { OnRefreshingPrincipal = previousCallback }; |
||||
|
|
||||
|
options.RemoveClientIdClaim().ShouldBeSameAs(options); |
||||
|
|
||||
|
await options.OnRefreshingPrincipal(context); |
||||
|
} |
||||
|
|
||||
|
private static void CopyClientIdForward(SecurityStampRefreshingPrincipalContext context) |
||||
|
{ |
||||
|
var clientId = context.CurrentPrincipal.FindFirst(AbpClaimTypes.ClientId); |
||||
|
if (clientId != null) |
||||
|
{ |
||||
|
context.NewPrincipal.Identities.First().AddClaim(clientId); |
||||
|
} |
||||
|
} |
||||
|
|
||||
|
private static SecurityStampRefreshingPrincipalContext CreateCorruptedCookieRefreshContext() |
||||
|
{ |
||||
|
return new SecurityStampRefreshingPrincipalContext |
||||
|
{ |
||||
|
CurrentPrincipal = CreateCookiePrincipal( |
||||
|
new Claim(AbpClaimTypes.UserId, "user-1"), |
||||
|
new Claim(AbpClaimTypes.ClientId, "MyClient")), |
||||
|
NewPrincipal = CreateCookiePrincipal(new Claim(AbpClaimTypes.UserId, "user-1")) |
||||
|
}; |
||||
|
} |
||||
|
|
||||
|
private static ClaimsPrincipal CreateCookiePrincipal(params Claim[] claims) |
||||
|
{ |
||||
|
return new ClaimsPrincipal(new ClaimsIdentity(claims, IdentityConstants.ApplicationScheme)); |
||||
|
} |
||||
|
} |
||||
@ -0,0 +1,82 @@ |
|||||
|
import { describe, expect, it } from 'vitest'; |
||||
|
import { createImportRefsToModelReducer } from '../utils/model'; |
||||
|
import { Type } from '../models/api-definition'; |
||||
|
import { ModelGeneratorParams } from '../utils/model'; |
||||
|
|
||||
|
// Reproduces #25080: when a DTO inherits from a generic base type (e.g. PagedResultDto<T>)
|
||||
|
// whose type argument T lives in the SAME namespace, the proxy generator used to emit an
|
||||
|
// invalid self-import (`import type { TransactionDto } from './models'`) inside models.ts,
|
||||
|
// breaking the Angular/TypeScript build.
|
||||
|
describe('proxy generation - self-import for generic base type argument (#25080)', () => { |
||||
|
const solution = 'MyApp'; |
||||
|
|
||||
|
// TransactionPagedResultDto : PagedResultDto<TransactionDto>, both in MyApp.Transactions.
|
||||
|
const types: Record<string, Type> = { |
||||
|
'MyApp.Transactions.TransactionDto': { |
||||
|
baseType: null, |
||||
|
isEnum: false, |
||||
|
enumNames: null, |
||||
|
enumValues: null, |
||||
|
genericArguments: null, |
||||
|
properties: [ |
||||
|
{ |
||||
|
name: 'Id', |
||||
|
jsonName: null, |
||||
|
type: 'System.Guid', |
||||
|
typeSimple: 'System.Guid', |
||||
|
isRequired: false, |
||||
|
isNullable: false, |
||||
|
}, |
||||
|
], |
||||
|
}, |
||||
|
'MyApp.Transactions.TransactionPagedResultDto': { |
||||
|
baseType: 'Volo.Abp.Application.Dtos.PagedResultDto<MyApp.Transactions.TransactionDto>', |
||||
|
isEnum: false, |
||||
|
enumNames: null, |
||||
|
enumValues: null, |
||||
|
genericArguments: null, |
||||
|
properties: [ |
||||
|
{ |
||||
|
name: 'AmountSummary', |
||||
|
jsonName: null, |
||||
|
type: 'System.Int32', |
||||
|
typeSimple: 'number', |
||||
|
isRequired: false, |
||||
|
isNullable: false, |
||||
|
}, |
||||
|
], |
||||
|
}, |
||||
|
}; |
||||
|
|
||||
|
const params: ModelGeneratorParams = { |
||||
|
targetPath: 'src/app/proxy', |
||||
|
solution, |
||||
|
types, |
||||
|
serviceImports: {}, |
||||
|
modelImports: {}, |
||||
|
}; |
||||
|
|
||||
|
it('does not emit a self-import for a same-namespace generic base argument', () => { |
||||
|
const reduce = createImportRefsToModelReducer(params); |
||||
|
const models = reduce([], ['MyApp.Transactions.TransactionPagedResultDto']); |
||||
|
|
||||
|
const model = models.find(m => m.namespace === 'Transactions'); |
||||
|
expect(model).toBeDefined(); |
||||
|
|
||||
|
// The buggy behavior produced an import with path './models' (a self-import).
|
||||
|
const selfImports = model!.imports.filter(i => i.path === './models'); |
||||
|
expect(selfImports).toEqual([]); |
||||
|
|
||||
|
// Sanity: TransactionDto must NOT be imported at all, since it is declared in this same file.
|
||||
|
const importsTransactionDto = model!.imports.some(i => |
||||
|
i.specifiers.some(s => s === 'TransactionDto'), |
||||
|
); |
||||
|
expect(importsTransactionDto).toBe(false); |
||||
|
|
||||
|
// The framework base type, however, should still be imported from @abp/ng.core.
|
||||
|
const importsPagedResultDto = model!.imports.some( |
||||
|
i => i.path === '@abp/ng.core' && i.specifiers.includes('PagedResultDto'), |
||||
|
); |
||||
|
expect(importsPagedResultDto).toBe(true); |
||||
|
}); |
||||
|
}); |
||||
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue