Components will allow your team to create stateful dependencies which can be injected and used through-out your web application without worrying about the scope of the dependency. It also provides an easy mechanism to quickly transfer state from one scope to the other, with ease. 

The container uses reflection-based scaffolding on your Applications assemblies to auto-register your components and makes sure they follow a life-cycle you can rely on.

Each component, once discovered and bound, takes part in a direct life-cycle which maps to web requests and will allow safe create/disposal logic within your app.

What is a Component, really?

A WebStack component is an concrete type that implements IComponent.

There are three types of components:

When you create your components, just decide which scope you would like the instance to be registered within and the WebStack Container Module will make sure that instances are resolved based on the Web Context of your application.

Typically, components represent an ‘aspect’ of work which can be implemented without the concerns of the framework in which it is hosted.

Component Scope Registrations

The WebStack Container API supports two different binding approaches.

Annotation-Driven Registration

Any class that inherits from IComponent and contains a Scope attribute will be registered in the associated instance scope.

The supported Scope attributes are ApplicationScoped, SessionScoped and RequestScoped.

Interface-Driven Registration

Any class that inherits from either IApplicationComponent, ISessionComponent or IRequestComponent will be registered in the associated instance scope.

Composite Interface Bindings

You can also inherit from any baseclass or implement any interface on your concrete instances, in addition to the component registration requirements.

The WebStack Container will make sure you get the right instance in the right scope, no matter how you request it.

For instance, if you have a business process interface defined as:

Which you have determined is a Workflow that should be instanced per User/Session, you would create your concrete implementation as follows:

Now, all requested injections of IMyBusinessProcess would resolve to a new instance per user session!

You will receive clear life-cycle events and may implement your workflow free of web concerns.

Building Your Components

There are three patterns I recommended for Component design:

Isolated Components

With an Isolated Component, the component does not contain an API definition and is designed to work only against the Component Life-Cycle.

1. 1. Build your component without an custom interface
2. 2. Register it in one of the three supported scopes
3. 3. Rely on the life-cycle to drive the components unit-of-work.

As an example, consider a Component that updates the DB’s Keep-Alive record for a signed in user:

In this example, the KeepAliveService does not implement its own api and it’s process is coupled to only the Request Component Life-Cycle.

Individual Components

An Individual Component acts as an application-accessible api that uses the Component Life-cycle to control its transaction boundaries.

1. 1. Build your component against a proprietary service definition
2. 2. Register the component in one of the three supported scopes
3. 3. Allow the Component Life-Cycle to build up the component state for use as an API against the proprietary service definition

As an example, consider a Component that logs how many times a Web User opens an email during the life-time of their Session.

We would create an interface that will be called from our Web Controllers to trigger the event:

Then, in our component implementation we would allow the count of emails to be held until the end of the user’s session, where we could commit the result to the DB:

The Web Application could then request instances of the IEmailTracker without the concerns of its transaction scope.

Community Components

An Community Component is a Stateful workflow which uses the Component Life-cycle to control its transaction bounds, but also has dependencies on other components.

1. 1. Build your component against a proprietary service definition
2. 2. Register the component in one of the three supported scopes
3. 3. Inject instances of other components needed to perform work
4. 4. Allow the Component Life-Cycle to build up the component state for use as an API against the proprietary service definition

As an example, consider a requirement to Log Open-Email events in our SessionEmailTracker (see “Individual Component” example above).

We can create a new component that will allow us to commit logging events per request , even from a Session scoped component:

We simply inject this into our Email Tracker component as follows:

Now, even though the SessionEmailTracker is executing as a Session Component, it will resolve the logger to a Request Scoped component.

Then, at the end of each request the logging message will be committed to the DB.

Manually Get the Components

For those that have their own patterns, the NInject Kernel can be interacted with via the IContainerManager instance on the ContainerModule.

Simply call BuildUp(this) on your class to have properties with the [Inject] attribute resolved.

Here is a sample WebForm using this pattern:

Project Source

	git@github.com:DeepElement/DeepElement.WebStack.git
	http://nuget.org/packages/WebStack.Modules.Container