Introducing Namotion.Interceptor for .NET

Namotion.Interceptor is a new .NET library for reactive object models. It is under active development and APIs may still change between versions.

It is designed for any .NET application where a domain model needs to be reactive: industrial automation, IoT, real-time UIs, digital twins, MVVM desktop apps, or anything where local property changes should propagate automatically to derived state, observers, or external systems. The design hinges on C# 13 partial properties, a recent language feature that lets a source generator emit real getters and setters for your properties without proxies, weaving, or base-class requirements. From the start, the project also optimizes hard for low allocations and high throughput, since interceptor libraries tend to sit on the hot path of high-frequency systems.

In practice, mark a class with [InterceptorSubject], declare your properties as partial, and the source generator handles the rest. You get automatic change events, derived properties, lifecycle callbacks, and INotifyPropertyChanged support, all generated at compile-time.

[InterceptorSubject]
public partial class Person
{
    public partial string FirstName { get; set; }
    public partial string LastName { get; set; }

    [Derived]
    public string FullName => $"{FirstName} {LastName}";
}

var context = InterceptorSubjectContext
    .Create()
    .WithFullPropertyTracking();

var person = new Person(context);
context.GetPropertyChangeObservable().Subscribe(c =>
    Console.WriteLine($"{c.Property.Name}: {c.GetNewValue<object?>()}"));

person.FirstName = "John";
// FirstName: John
// FullName: John

The library is structured as six packages, each building on the previous so you can adopt only what you need:

• Core provides [InterceptorSubject], the source generator, and the read/write interceptor pipeline that everything else plugs into.
• Tracking adds observable and queue-based change streams, automatic recalculation of [Derived] properties, lifecycle attach/detach events, and atomic transactions.
• Validation rejects invalid writes using standard [Required], [MaxLength], [Range] attributes or custom validators.
• Registry keeps a runtime catalog of every subject and property, enables strongly-typed metadata via property attributes, dynamic property creation, and stable subject IDs.
• Connectors synchronize the object graph with external systems. Bidirectional MQTT, OPC UA, and WebSocket integrations are included, along with infrastructure for custom connectors.
• Integrations expose subjects through .NET host frameworks: ASP.NET Core (REST + JSON), Blazor (auto re-rendering with <TrackingScope>), HotChocolate (GraphQL subscriptions), and MCP (so AI agents can browse and manipulate the object graph).

For example, wiring a subject to an MQTT broker is roughly two steps:

[InterceptorSubject]
public partial class Sensor
{
    [Path("mqtt", "temperature")]
    public partial decimal Temperature { get; set; }
}

builder.Services.AddMqttSubjectClient<Sensor>(
    brokerHost: "mqtt.example.com",
    sourceName: "mqtt",
    brokerPort: 1883,
    topicPrefix: "sensors/room1");

Local writes to sensor.Temperature are now published to the broker, and inbound MQTT messages update the property and trigger change notifications. The same pattern works for OPC UA, WebSocket, or your own custom connector.

A typical use case is an IoT or industrial scenario where the same C# domain model is the source of truth for a Blazor dashboard, the contract for an OPC UA client talking to a PLC, and the wire format for an MQTT bridge, without writing protocol glue code by hand.

It also powers HomeBlaze v2, a complete rewrite of my home automation platform for .NET and Blazor, now built on Namotion.Interceptor for all device modeling and synchronization. The v2 codebase currently lives alongside the library in the same repository while the two mature together, and will eventually be split out into its own repo (replacing the HomeBlaze v1 codebase there). HomeBlaze is also the primary driver behind many of the library’s design decisions.

Feedback, issues, and contributions are very welcome. Source code and documentation can be found on GitHub