Skip to content

Add examples for DynamicProxy, Pooling, DotGraph, and multitenant ASP.NET Core - #40

Merged
tillig merged 3 commits into
mainfrom
feature/new-examples
Sep 1, 2026
Merged

Add examples for DynamicProxy, Pooling, DotGraph, and multitenant ASP.NET Core#40
tillig merged 3 commits into
mainfrom
feature/new-examples

Conversation

@tillig

@tillig tillig commented Sep 1, 2026

Copy link
Copy Markdown
Member

Part of #32

First half of item 8. The middleware example for autofac/Documentation#160 follows separately, alongside the documentation changes it needs.

Proposed Changes

Four shipping packages had no example at all. Now they do.

Example Shows
DynamicProxyExample Interception wired two ways: named on the registration, and declared with [Intercept] on the contract
PoolingExample Instance reuse across lifetime scopes, plus a pool policy that resets an instance on return
DotGraphExample Capturing a resolve operation as a Graphviz graph
AspNetCoreMultitenantExample Per-tenant registration overrides in ASP.NET Core, tenant taken from the query string

Each one is registered in Examples.slnx, has a launch configuration, a README, and a row in the root README table.

Choices worth reviewing

PoolingExample is built around its own output. A pooled registration looks like a singleton until you can see otherwise, so the example prints a line per construction and reports which instance each scope received. Sequential scopes share one instance; overlapping scopes each construct their own. The use count printed after reuse is 1 rather than 2, which is the proof that the policy reset the instance on its way back into the pool — that reset is the actual difference between pooling and SingleInstance.

DotGraphExample registers a decorator on purpose. A graph of three unrelated services is not worth rendering; an adapter chain is.

AspNetCoreMultitenantExample writes its own ITenantIdentificationStrategy. The package deliberately ships none — I checked the public surface rather than assuming, since the package README shows a QueryStringTenantIdentificationStrategy that the reader is expected to supply. The example also covers the case people get wrong: a tenant with no registered override falls back to the container default rather than failing.

DynamicProxyExample shows both wiring styles side by side, because "which one do I use" is the question, and either one alone reads like the only option.

Verification

All 19 projects build with 0 errors and 0 warnings in Release under the analyzer rules from #37, and both gates pass. Every example was executed:

  • DynamicProxyExample — both interceptor styles log the call and the return value.
  • PoolingExample — 2 connections constructed across 4 resolves, use count reset on return.
  • DotGraphExample — emits a .dot file, and I rendered it with Graphviz to confirm it actually parses rather than just looking plausible.
  • AspNetCoreMultitenantExample — no tenant and ?tenant=gamma both resolve the default; alpha and beta resolve their own overrides.

The launch configurations are checked with the same validator from #38: 11 configurations, 11 launchable projects, nothing missing and nothing orphaned. All 95 markdown links resolve, with repo links verified against each clone's origin remote and doc links mapped back to .rst files in the Documentation repo.

….NET Core

Four shipping packages had no example at all, which left the documentation as the
only reference for them.

DynamicProxyExample shows interception wired both ways, on the registration and
by attribute on the contract, because which one to reach for is the question
people actually have.

PoolingExample leans on its own output: sequential scopes share one instance
while overlapping scopes each construct their own, and the use count printed
after reuse proves the policy reset the instance on its way back to the pool.
That distinction is the whole difference between pooling and a singleton.

DotGraphExample includes a decorator so the captured graph has an adapter chain
worth looking at, rather than a flat list nobody needs a picture of.

AspNetCoreMultitenantExample writes its own ITenantIdentificationStrategy, since
the package deliberately ships none, and covers the case people get wrong: a
tenant with no override falls back to the container default rather than failing.

Part of #32
Matches the MultitenantExample.ConsoleApplication, .MvcApplication and
.WcfService naming already used for the other multitenant samples, so all four
sort together. Namespaces follow the project name, as they do in the sibling
projects.

It stays in the ASP.NET Core solution folder and the ASP.NET Core section of the
README, since that is where someone looking for ASP.NET Core would go first.

Part of #32
…ile each

The rename in the previous commit left MultitenantExample.AspNetCore sitting in
the alphabetical slot its old name occupied.

DotGraphExample kept six types in a single Services.cs, which does not match the
rest of the repository or the two sibling examples added alongside it. Split with
no behaviour change: the captured graph renders byte for byte identically.

Part of #32
@tillig
tillig merged commit 186975f into main Sep 1, 2026
8 checks passed
@tillig
tillig deleted the feature/new-examples branch September 1, 2026 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant