Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Decorator duplicates lifestyle of decorated instance

See original GitHub issue

The Decorate method creates a decorator that duplicates the lifestyle of the decorated instance. This means that if a service is a Singleton, all its decorators will be Singleton as well. There is currently no way to influence that behavior.

It’s quite common to have the need to register decorators with a lifestyle lower than their decoratees. For instance, even though the decoratee might be a singleton, its decorator might require a dependency on a scoped service (a DbContext for instance). This requires the decorator to have a lifestyle of scoped or transient.

On top of that, in case there are multiple services that apply to a decorator (when multiple registrations for the same service type exist), and those services have different lifestyles, so will the applied decorators. In other words, a registration for a certain decorator could cause different decorator instances to exist with different lifestyles. This could lead to confusion.

Appart from this, the chosen behavior is very different from what (most) DI Containers do. This could lead to confusion as well and perhaps problems when migrating from Scrutor to a custom DI Container or vice versa.

Is there a particular reason for this behavior?

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Reactions:3
  • Comments:19 (10 by maintainers)

github_iconTop GitHub Comments

dotnetjunkiecommented, Nov 16, 2017

Ah, I see. What you are saying is that giving the decorator a shorter lifetime than its decoratee, might cause the decorator to become a Captive Dependency when injected into a consumer.

This is absolutely correct, but on the other hand, as we discussed above, keeping the decorator’s lifestyle in sync with that of its decoratee will cause Captive Dependencies as well, in case the decorator takes a dependency on other services (other than the decoratee) that have a shorter lifetime than the decoratee.

The difference is, by making the decorator’s lifestyle fixing to that of its decoratee, it will be impossible for the user to fix a Captive Dependency when it occurs, while when it occurs with the configurable lifestyle, we actually have the ability to fix the problem.

That said, in either case, it is important to have some tooling that detects Captive Dependencies for us. Both Microsoft.Extensions.DependencyInjection, Autofac, Castle Windsor and Simple Injector do detect these problems (although with MS you will have to explicitly configure the container to do so).

dotnetjunkiecommented, Oct 16, 2017

If we introduced a way to influence this behavior, we’d make it much easier to do exactly what you’re advocating against below. Sounds like you’re requesting something that you’re fundamentally opposed to?

Do you mean you think I’m advocating against “having multiple registrations for the same service, with different lifestyles”? My text might have been confusing, but I’m actually not advocating against this. In my experience this is a really common use case and all DI containers (that I know of) do support this.

I would really vote to add this behavior, and further make transient the default lifestyle for a decorator, or make the overloads more explicit, i.e. DecorateTransient, DecorateScoped and DecorateSingleton.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Duplicated attributes in the decorator pattern
The decorator can lazily return data based on the object it decorate. It may have some attribute (like the 2 in my example), ......
Read more >
Decorator is a structural design pattern that lets you attach new behaviors to objects by placing these objects inside special wrapper objects that...
Read more >
4. Decorator Pattern - ActionScript 3.0 Design Patterns [Book]
In the context of this chapter, a component refers to a concrete instance that is decorated with another concrete instance called a decorator....
Read more >
Decorator in Delphi - Design Patterns
In this example, TTextStream defines an (abstract) interface which is decorated by a TTextFilter class. Here's the implementation: type TTextStream = class ( ......
Read more >
Gardner's Art through the Ages: A Global History - Google Books Result
May not be copied, scanned, or duplicated, in whole or in part. ... Te concentric circle design over his left shoulder, for example,...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found