You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/provider_memory.md
+61-37
Original file line number
Diff line number
Diff line change
@@ -19,91 +19,115 @@ Please read the [Introduction](intro.md) before reading this provider documentat
19
19
20
20
## Introduction
21
21
22
-
The Memory transport provider can be used for internal communication within the same process. It is the simplest transport provider and does not require any external messaging infrastructure.
22
+
The **Memory transport provider** enables message-based communication within a single process. It’s the simplest transport option in SlimMessageBus and doesn’t require any external infrastructure like Kafka or Azure Service Bus.
23
23
24
-
> Since messages are passed in memory and never persisted, they will be lost if the application process terminates while consuming these messages.
24
+
> ⚠️ Messages are passed entirely in memory and are never persisted. If the application process terminates while messages are in-flight, those messages will be lost.
25
25
26
-
Good use case for inmemory communication is:
26
+
**Common use cases for in-memory transport include:**
27
27
28
-
- to integrate the domain layer with other application layers via domain events pattern,
29
-
- to implement mediator pattern (when combined with [interceptors](intro.md#interceptors)),
30
-
- to run unit tests against application code that normally runs with an out of process transport provider (Kafka, Azure Service Bus, etc),
31
-
- to start simple messaging without having to provision messaging infrastructure, but when time comes reconfigure SMB to leverage messaging infrastructure.
28
+
- Integrating the domain layer with other application layers using the **domain events** pattern.
29
+
- Implementing the **mediator pattern** (especially when combined with [interceptors](intro.md#interceptors)).
30
+
- Writing **unit tests** for messaging logic without requiring a full transport setup.
31
+
- Starting with messaging quickly and easily — no infrastructure required — and switching to an external provider later by reconfiguring SlimMessageBus.
32
+
33
+
---
32
34
33
35
## Configuration
34
36
35
-
The memory transport is configured using the `.WithProviderMemory()`:
37
+
First, install the NuGet package:
36
38
37
-
```cs
39
+
```bash
40
+
dotnet add package SlimMessageBus.Host.Memory
41
+
```
42
+
43
+
Then, configure the memory transport using `.WithProviderMemory()`:
> 💡 No serializer is needed by default for the in-memory transport — unless you [opt in to serialization](#serialization).
56
+
47
57
### Virtual Topics
48
58
49
-
Unlike other transport providers, memory transport does not have true notion of topics (or queues). However, it is still required to use topic names. This is required, so that the bus knows on which virtual topic to deliver the message to, and from what virtual topic to consume from.
59
+
The in-memory transport doesn't use real topics or queues like other transport providers. However, **virtual topic names** are still required. These names allow the bus to correctly route messages to and from the appropriate consumers.
50
60
51
-
The consumer configuration side should use `.Topic()` to set the virtual topic name:
61
+
On the **consumer side**, use `.Topic()` to specify the virtual topic:
52
62
53
-
```cs
54
-
//declare that OrderSubmittedEvent will be consumed
> The virtual topic name can be any string. It helps to connect the relevant producers and consumers together.
77
+
> Virtual topic names can be any string, as long as producers and consumers use the same value. This is what links them together internally.
68
78
69
79
### Auto Declaration
70
80
71
-
For bus configuration, we can leverage `.AutoDeclareFrom()` methodto discover all the consumers (`IConsumer<T>`) and handlers (`IRequestHandler<T,R>`) types in an assembly and auto declare the respective producers and consumers/handlers in the bus.
72
-
This can be useful to auto declare all of the domain event handlers in an application layer.
81
+
You can simplify your bus configuration using the `.AutoDeclareFrom()` method, which scans an assembly to automatically discover all consumers (`IConsumer<T>`) and handlers (`IRequestHandler<T,R>`). It then declares the corresponding producers and consumers/handlers on the bus for you.
82
+
This is especially useful for automatically registering all domain event handlers within an application layer.
The virtual topic name will be derived from the message type name by default. This can be customized by passing an additional parameter to the `AutoDeclareFrom()` method.
118
+
By default, the virtual topic name is derived from the message type’s [`FullName`](https://learn.microsoft.com/en-us/dotnet/api/system.type.fullname?view=net-9.0) — meaning it includes both the namespace and any outer class names.
119
+
You can customize this by providing your own `messageTypeToTopicConverter`:
Using `.AutoDeclareFrom()`to configure the memory bus is recommended, as it will declare the producers and consumers automatically as consumer types are added over time.
128
+
Using `.AutoDeclareFrom()`is highly recommended when configuring the memory bus, as it ensures producers and consumers are kept up to date automatically as your application evolves.
105
129
106
-
> The`.AutoDeclareFrom()` and `.AutoDeclareFromAssembly<T>()` will also register the found consumers/handlers into MSDI (see [here](intro.md#autoregistration-of-consumers-interceptors-and-configurators)).
130
+
> Note:`.AutoDeclareFrom()` and `.AutoDeclareFromAssemblyContaining<T>()` will also register discovered consumers and handlers into the Microsoft Dependency Injection (MSDI) container. [Learn more here](intro.md#autoregistration-of-consumers-interceptors-and-configurators).
Copy file name to clipboardExpand all lines: docs/provider_memory.t.md
+61-37
Original file line number
Diff line number
Diff line change
@@ -19,91 +19,115 @@ Please read the [Introduction](intro.md) before reading this provider documentat
19
19
20
20
## Introduction
21
21
22
-
The Memory transport provider can be used for internal communication within the same process. It is the simplest transport provider and does not require any external messaging infrastructure.
22
+
The **Memory transport provider** enables message-based communication within a single process. It’s the simplest transport option in SlimMessageBus and doesn’t require any external infrastructure like Kafka or Azure Service Bus.
23
23
24
-
> Since messages are passed in memory and never persisted, they will be lost if the application process terminates while consuming these messages.
24
+
> ⚠️ Messages are passed entirely in memory and are never persisted. If the application process terminates while messages are in-flight, those messages will be lost.
25
25
26
-
Good use case for inmemory communication is:
26
+
**Common use cases for in-memory transport include:**
27
27
28
-
- to integrate the domain layer with other application layers via domain events pattern,
29
-
- to implement mediator pattern (when combined with [interceptors](intro.md#interceptors)),
30
-
- to run unit tests against application code that normally runs with an out of process transport provider (Kafka, Azure Service Bus, etc),
31
-
- to start simple messaging without having to provision messaging infrastructure, but when time comes reconfigure SMB to leverage messaging infrastructure.
28
+
- Integrating the domain layer with other application layers using the **domain events** pattern.
29
+
- Implementing the **mediator pattern** (especially when combined with [interceptors](intro.md#interceptors)).
30
+
- Writing **unit tests** for messaging logic without requiring a full transport setup.
31
+
- Starting with messaging quickly and easily — no infrastructure required — and switching to an external provider later by reconfiguring SlimMessageBus.
32
+
33
+
---
32
34
33
35
## Configuration
34
36
35
-
The memory transport is configured using the `.WithProviderMemory()`:
37
+
First, install the NuGet package:
36
38
37
-
```cs
39
+
```bash
40
+
dotnet add package SlimMessageBus.Host.Memory
41
+
```
42
+
43
+
Then, configure the memory transport using `.WithProviderMemory()`:
> 💡 No serializer is needed by default for the in-memory transport — unless you [opt in to serialization](#serialization).
56
+
47
57
### Virtual Topics
48
58
49
-
Unlike other transport providers, memory transport does not have true notion of topics (or queues). However, it is still required to use topic names. This is required, so that the bus knows on which virtual topic to deliver the message to, and from what virtual topic to consume from.
59
+
The in-memory transport doesn't use real topics or queues like other transport providers. However, **virtual topic names** are still required. These names allow the bus to correctly route messages to and from the appropriate consumers.
50
60
51
-
The consumer configuration side should use `.Topic()` to set the virtual topic name:
61
+
On the **consumer side**, use `.Topic()` to specify the virtual topic:
52
62
53
-
```cs
54
-
//declare that OrderSubmittedEvent will be consumed
> The virtual topic name can be any string. It helps to connect the relevant producers and consumers together.
77
+
> Virtual topic names can be any string, as long as producers and consumers use the same value. This is what links them together internally.
68
78
69
79
### Auto Declaration
70
80
71
-
For bus configuration, we can leverage `.AutoDeclareFrom()` methodto discover all the consumers (`IConsumer<T>`) and handlers (`IRequestHandler<T,R>`) types in an assembly and auto declare the respective producers and consumers/handlers in the bus.
72
-
This can be useful to auto declare all of the domain event handlers in an application layer.
81
+
You can simplify your bus configuration using the `.AutoDeclareFrom()` method, which scans an assembly to automatically discover all consumers (`IConsumer<T>`) and handlers (`IRequestHandler<T,R>`). It then declares the corresponding producers and consumers/handlers on the bus for you.
82
+
This is especially useful for automatically registering all domain event handlers within an application layer.
The virtual topic name will be derived from the message type name by default. This can be customized by passing an additional parameter to the `AutoDeclareFrom()` method.
118
+
By default, the virtual topic name is derived from the message type’s [`FullName`](https://learn.microsoft.com/en-us/dotnet/api/system.type.fullname?view=net-9.0) — meaning it includes both the namespace and any outer class names.
119
+
You can customize this by providing your own `messageTypeToTopicConverter`:
Using `.AutoDeclareFrom()`to configure the memory bus is recommended, as it will declare the producers and consumers automatically as consumer types are added over time.
128
+
Using `.AutoDeclareFrom()`is highly recommended when configuring the memory bus, as it ensures producers and consumers are kept up to date automatically as your application evolves.
105
129
106
-
> The`.AutoDeclareFrom()` and `.AutoDeclareFromAssembly<T>()` will also register the found consumers/handlers into MSDI (see [here](intro.md#autoregistration-of-consumers-interceptors-and-configurators)).
130
+
> Note:`.AutoDeclareFrom()` and `.AutoDeclareFromAssemblyContaining<T>()` will also register discovered consumers and handlers into the Microsoft Dependency Injection (MSDI) container. [Learn more here](intro.md#autoregistration-of-consumers-interceptors-and-configurators).
0 commit comments