Child kernel versus named scope

Many Object Graphs lend themselves to being modelled with the notion of a 'child' Kernel instead of a Named Scope. In the first InNamedScope example it is possible to create a new 'child' Kernel per sheet and declare the data repository InSingletonScope. There are pros and cons to both of these approaches.

Pro Child Kernel:

• Guaranteed no side effects. e.g. even if a binding is defined incorrectly, the various worksheets can not have any impact to each other. Imagine if we were using a Named Scope and mistakenly declared a dependency as InSingletonScope() instead of InNamedScope(). In this case the Sheets would share the instance and influence each other.
• Enables two different types of worksheets. If you have worksheets that behave differently you can Load() a different set of Bindings into the 'child' instead of having to define Conditional Bindings. This can make things much easier in most cases.

Pro Named Scope:

• Faster: Ninject will do the analysis of the classes only once and build up the plans on the first resolve. All further Resolves won’t have to do the planning again.
• Shared bindings can use the ones defined for the Named Scope. The 'child' Kernel has the restriction that bindings declared in the 'parent' Kernel can not be accessed from the 'child' Kernel.

Related

• Home
• Applied mechanisms: InCallScope, InParentScope
• General mechanism: InNamedScope
• Low level programmatic mechanism: CreateNamedScope/GetScope
• Discussion blog post from Remo Gloor re notion of 'Activation Blocks'
• (Largely Historical) blog post on Cache and Collect also touches on the original motivation for the Activation Blocks capability in Ninject 2+