In this follow up post I try to tackle the more advanced stuff which is possible with the new ninject extension for Windows Workflow Foundation. The goal is to show the following topics:
In my last post I raised the following questions:
In this follow up post I try to answer these questions.
The Named Scope extension adds the three additional Scopes InCallScope, InNamedScope and InParentScope to Ninject. In this Blogpost I want to explain how they are used. Some parts of this post expect that you have a basic knowledge about the Context Preservation extension. Consider reading my blog post about the Context Preservation Extension before reading this one.
In this blog post I explain how the Context Preservation extension works and for what it is used.
Windows Workflow Foundation 4 offers a comprehensive set of tools to design, create and host your own workflows in your application. Normally when working with WF4 the only way to get your external dependencies into the workflow is by passing the dependencies as arguments to the workflow host such as WorkflowApplication, WorkflowInvoker or WorkflowServiceHost.
MVC3 added support for Dependency Injection frameworks. To take advantage of these features I did a completely new implementation of the Ninject.Web.Mvc extension. Unlike other existing MVC3 implementations for Ninject, this extension goes further than just adding a IDependencyResolver for Ninject. It has tightly Ninject integrated support for various things such as Filters and Validators.
This post assumes that you have a basic knowledge about MVC, Ninject and Dependency Injection in general.
In the last post, I showed you the big picture of my UI design pattern. Before I can start showing you sample code for the different parts, I need to introduce some tools, which are used to glue all the tiny parts together: