|
| 1 | +--- |
| 2 | +type: docs |
| 3 | +title: "DaprWorkflowClient usage" |
| 4 | +linkTitle: "DaprWorkflowClient usage" |
| 5 | +weight: 100000 |
| 6 | +description: Essential tips and advice for using DaprWorkflowClient |
| 7 | +--- |
| 8 | + |
| 9 | +## Lifetime management |
| 10 | + |
| 11 | +A `DaprWorkflowClient` holds access to networking resources in the form of TCP sockets used to communicate with the Dapr sidecar as well |
| 12 | +as other types used in the management and operation of Workflows. `DaprWorkflowClient` implements `IAsyncDisposable` to support eager |
| 13 | +cleanup of resources. |
| 14 | + |
| 15 | +## Dependency Injection |
| 16 | + |
| 17 | +The `AddDaprWorkflow()` method will register the Dapr workflow services with ASP.NET Core dependency injection. This method |
| 18 | +requires an options delegate that defines each of the workflows and activities you wish to register and use in your application. |
| 19 | + |
| 20 | +{{% alert title="Note" color="primary" %}} |
| 21 | + |
| 22 | +This method will attempt to register a `DaprClient` instance, but this will only work if it hasn't already been registered with another |
| 23 | +lifetime. For example, an earlier call to `AddDaprClient()` with a singleton lifetime will always use a singleton regardless of the |
| 24 | +lifetime chose for the workflow client. The `DaprClient` instance will be used to communicate with the Dapr sidecar and if it's not |
| 25 | +yet registered, the lifetime provided during the `AddDaprWorkflow()` registration will be used to register the `DaprWorkflowClient` |
| 26 | +as well as its own dependencies. |
| 27 | + |
| 28 | +{{% /alert %}} |
| 29 | + |
| 30 | +### Singleton Registration |
| 31 | +By default, the `AddDaprWorkflow` method will register the `DaprWorkflowClient` and associated services using a singleton lifetime. This means |
| 32 | +that the services will be instantiated only a single time. |
| 33 | + |
| 34 | +The following is an example of how registration of the `DaprWorkflowClient` as it would appear in a typical `Program.cs` file: |
| 35 | + |
| 36 | +```csharp |
| 37 | +builder.Services.AddDaprWorkflow(options => { |
| 38 | + options.RegisterWorkflow<YourWorkflow>(); |
| 39 | + options.RegisterActivity<YourActivity>(); |
| 40 | +}); |
| 41 | + |
| 42 | +var app = builder.Build(); |
| 43 | +await app.RunAsync(); |
| 44 | +``` |
| 45 | + |
| 46 | +### Scoped Registration |
| 47 | + |
| 48 | +While this may generally be acceptable in your use case, you may instead wish to override the lifetime specified. This is done by passing a `ServiceLifetime` |
| 49 | +argument in `AddDaprWorkflow`. For example, you may wish to inject another scoped service into your ASP.NET Core processing pipeline |
| 50 | +that needs context used by the `DaprClient` that wouldn't be available if the former service were registered as a singleton. |
| 51 | + |
| 52 | +This is demonstrated in the following example: |
| 53 | + |
| 54 | +```csharp |
| 55 | +builder.Services.AddDaprWorkflow(options => { |
| 56 | + options.RegisterWorkflow<YourWorkflow>(); |
| 57 | + options.RegisterActivity<YourActivity>(); |
| 58 | +}, ServiceLifecycle.Scoped); |
| 59 | + |
| 60 | +var app = builder.Build(); |
| 61 | +await app.RunAsync(); |
| 62 | +``` |
| 63 | + |
| 64 | +### Transient Registration |
| 65 | + |
| 66 | +Finally, Dapr services can also be registered using a transient lifetime meaning that they will be initialized every time they're injected. This |
| 67 | +is demonstrated in the following example: |
| 68 | + |
| 69 | +```csharp |
| 70 | +builder.Services.AddDaprWorkflow(options => { |
| 71 | + options.RegisterWorkflow<YourWorkflow>(); |
| 72 | + options.RegisterActivity<YourActivity>(); |
| 73 | +}, ServiceLifecycle.Transient); |
| 74 | + |
| 75 | +var app = builder.Build(); |
| 76 | +await app.RunAsync(); |
| 77 | +``` |
0 commit comments