Skip to content

InCallScope

Jump to bottom Edit New page
bartelink edited this page Aug 1, 2013 · 10 revisions

A Binding configured as InCallScope() will yield the same instance of Service Type T for every Resolve of T within a set of objects Composed in a single call to [ContextPreserving]Get<T>().

Contrasting it to InNamedScope, one would say its a limited version of InNamedScope() that automatically adds an anonymous Named Scope to the Root object generated by the Get<T>() which is shared with all other InCallScope() objects generated as part of the same Call. One key difference is that a ContextPreservingGet<T>(), or a Create...()/Get...() in a generated Factory constitutes a fresh Call Scope. In other words, there will be a separate shared instance of T for every Call to [ContextPreserving]Get<T>() (this applies equally to Gets happening under the covers in a generated Factory and ones triggered by Bind()...ToMethod() bindings used as part of the overall call).

As with InNamedScope, all objects in a Call Scope are Collected and Deactivated together. Instances are tracked by the Kernel (as opposed to InTransientScope(), see Scopes)

InNamedScope example #1 rewritten with InCallScope()

Scenario #1 outlined in the InNamedScope example, can be expressed as follows using the InCallScope() mechanism.

Bind<SheetDataRepository>().ToSelf().InCallScope();
Bind<ExcelSheet>().ToSelf();
Bind<SheetPresenter>().ToSelf();
Bind<SheetCalculator>().ToSelf();

InNamedScope example #2 cannot be expressed using InCallScope()

Scenario #2 in the InNamedScope example can not be modelled using InCallScope() as CreateCellCalculator() on the generated Factory would produce a new SheetDataRepository for each invocation.

Change in behaviour in 3.0.1 vs 3.0.0

In 3.0.0, a ContextPreservingGet had the effect of extending the Call Scope in two key cases

  • within a Resolve action which leads to a Resolve of the same T within the overall call (e.g. if a Get<T>() leads to a nested Resolve using a Bind...ToMethod(context=>context.ContextPreservingGet<T>() ..., the same object would be returned and any objects of a different type generated anywhere in the overall Request would be in the same Scope)
  • within any Resolve happening within a IResolutionRoot used e.g. within a generated Factory). This meant that all objects emanating from Factories generated by a single Composition were scoped together. In 3.0.1 (which can be gotten as the Unstable (i.e. -Pre) NuGet packages as of 29/3/13, the behaviour is as described in the earlier sections, i.e. each Call is discrete.

The old behaviour was an oversight and was changed on the basis that the 3.0.0 behaviour represents a bug.

Related

Add a custom footer
Add a custom sidebar
Clone this wiki locally