I'm trying to work on a legacy application (with source) to implement IoC using Unity.
The problem I am currently facing is that, Ive got 2 classes that is circular referencing each other.
Class A reference Class B
Class B reference Class A
I inject each of the dependency by using property setter with annotiation;
On class A:
[Dependency]
public IServiceA ServiceA { get; set; }
On class B:
[Dependency]
public IServiceB ServiceB { get; set; }
Unity will go into a circular referencing because of this.
Is there a way to go around (besides refactoring the methods inside) as these classes are legacy and I do not want to spend so much effort in changing the design of them?
Unity will do this steps when you try to resolve A.
Create A
Look at Properties for A and create them
Found B will create B
Look at Properties for B and create them
Found A will Create A
You are stuck in a loop.
Your best option is to create C which A and B depend on. However C does not depend on A or B.
I agree that refactoring is the best practice, but you can achieve what you are after by changing one or both of the properties to be Lazy<T>. Then Unity will not resolve the other instance until you use that property.
On class A:
[Dependency]
public Lazy<IServiceA> ServiceA { get; set; }
On class B:
[Dependency]
public Lazy<IServiceB> ServiceB { get; set; }
Or you could change their registration lifetimes so they reuse the same instances. This may not work for you though if you do not want the same instances to be shared. Maybe PerResolveLifetime would work?
Resolve A (Instantiate A)
Detects B dependency
Resolve B (Instantiate B)
Detects A dependency
Resolve A (Reuse instance A due to lifetime and completes recursion)
Example:
container.RegisterType<A>(new PerResolveLifetimeManager());
This is a frustrating limitation of Unity indeed. However, there is a 2-pass solution:
[TestClass]
public class UnityTests
{
[TestMethod]
public void Cure_For_UnityNotBeingVerySmartAtBindingCircularDependentProperties()
{
var container = new UnityContainer();
container.RegisterType<ISharedResource, SharedResource>(new ContainerControlledLifetimeManager());
container.RegisterType<ICycleA, CycleA>(new ContainerControlledLifetimeManager(), new InjectionProperty("SharedResource"));
container.RegisterType<ICycleB, CycleB>(new ContainerControlledLifetimeManager(), new InjectionProperty("SharedResource"));
var a = container.Resolve<ICycleA>();
var b = container.Resolve<ICycleB>();
container.RegisterType<ICycleA, CycleA>("buildup", new ContainerControlledLifetimeManager());
container.RegisterType<ICycleB, CycleB>("buildup", new ContainerControlledLifetimeManager());
container.BuildUp(a, "buildup");
container.BuildUp(b, "buildup");
Assert.IsInstanceOfType(a, typeof(CycleA));
Assert.IsInstanceOfType(a.Dependency, typeof(CycleB));
Assert.AreSame(a, a.Dependency.Dependency);
}
}
internal interface ISharedResource { }
class SharedResource : ISharedResource { }
class CycleB : ICycleB
{
[Dependency]public ISharedResource SharedResource { get; set; }
[Dependency]public ICycleA Dependency { get; set; }
}
class CycleA : ICycleA
{
[Dependency]public ISharedResource SharedResource { get; set; }
[Dependency]public ICycleB Dependency { get; set; }
}
interface ICycleB
{
[Dependency]ISharedResource SharedResource { get; set; }
[Dependency]ICycleA Dependency { get; set; }
}
interface ICycleA
{
[Dependency]ISharedResource SharedResource { get; set; }
[Dependency]ICycleB Dependency { get; set; }
}
It takes advantage of the InjectionProperty overload which tells Unity to only wire up the specified Dependencies.
If your classes have a shared resource (e.g Logging service), register this Dependency on the 1st pass, with the final BuildUp pass connecting all the classes together.
It does require a call to Resolve and BuildUp on all classes, a little awkward but can be automated with UnityContainer extensions fairly easily.
This should be addressed by Microsoft as it is a fairly standard use case.
Related
So I have this data class:
public class RecentProject
{
public string ProjectName { get; set; }
public string ProjectPath { get; set; }
public DateTime CreationDate { get; set; }
public string OutputFolder { set; get; } = "";
}
It just defines the properties of the recent project, and I wanted to apply dependency inversion so I extracted an interface from the class:
public interface IRecentProject
{
DateTime CreationDate { get; set; }
string OutputFolder { get; set; }
string ProjectName { get; set; }
string ProjectPath { get; set; }
}
then I made an ioc container(inversion of control) and registered the class type as the interface:
Mvx.IoCProvider.RegisterType<IRecentProject, RecentProject>();
so anywhere in my app when I want to create a recent project I just use:
Mvx.IoCProvider.Resolve<IRecentProject>();
but after I did this I ran into some problems that would be hard to solve with the current setup so I thought that maybe this is not the correct way to apply dependency inversion in this class because none of the dependency inversion benefits would apply like:
unit testing: as I will not be unit testing a data class
The ability to change the class implementation: as any changes in the class will require a change in the interface to be able to use the new features added
So what should I do, I have searched a lot on this topic and could not find a clear answer,
please help and thanks in advance.
If RecentProject is a pure data class, that is it contains no logic, then indeed no need either for unit testing or for abstraction. And of course, IoC is out of scope here.
Things look different when logic and polymorphism are involved. You may want, for example, to have two types of projects with each implementing name validation in its own (simplistic) way:
public class RecentCSharpProject : IRecentProject
{
.
.
.
public string ProjectName
{
get => this.projectName;
set
{
if (!value.EndsWith("csproj"))
{
throw (new Exception("This is not a C# project"));
}
this.projectName = value;
}
}
}
public class RecentFSharpProject : IRecentProject
{
.
.
.
public string ProjectName
{
get => this.projectName;
set
{
if (!value.EndsWith("fsproj"))
{
throw (new Exception("This is not an F# project"));
}
this.projectName = value;
}
}
}
You may still choose to skip unit tests, plus IoC still irrelevant (services are to be injected, not data models).
However, you will now be able to instantiate appropriate class while still "speaking" the interface language to the outside world:
public IRecentProject AddProjectToFileMenu(string projectName, bool isFSharp)
{
IRecentProject project = (isFSharp ? new RecentFSharpProject() : new RecentCSharpProject());
project.ProjectName = projectName; // Internally validate extension according to concrete class
// TODO: add project to file-menu
return (project);
}
I'm building a password generator. I'm trying to apply the Dependency Inversion Principle (DIP) but so far my solution still seems to be coupled with concrete data.
How do I decouple the PasswordGenerator? So I don't have to pass to it
new PasswordRequirementsRepository(new PasswordRequirements{[properties assigned here]})
and I can inject an interface instead which will be used by IoC Container?
How can I pass in the data assigned to PasswordRequirements properties to the PasswordGenerator without creating an instance of PasswordRequirementsRepository?
I'm struggling when passing different sets of password requirements because in PasswordGenerator I have to pass a concrete instance of PasswordRequirementsRepository instead of interface. I guess what I'm trying to achieve is to decouple PasswordGenerator from the concrete set of password requirements.
IPasswordRequirementsRepository.cs
public interface IPasswordRequirementsRepository
{
PasswordRequirements GetPasswordRequirements();
}
PasswordRequirementsRepository.cs
public class PasswordRequirementsRepository : IPasswordRequirementsRepository
{
private readonly PasswordRequirements _requirements;
public PasswordRequirementsRepository(PasswordRequirements requirements)
{
_requirements = requirements;
}
public PasswordRequirements GetPasswordRequirements()
{
return _requirements;
}
}
IPasswordGenerator.cs
public interface IPasswordGenerator
{
string GeneratePassword();
}
PasswordGenerator.cs
public class PasswordGenerator : IPasswordGenerator
{
private readonly IPasswordRequirementsRepository _repository;
public PasswordGenerator(IPasswordRequirementsRepository repository)
{
_repository = repository;
}
public string GeneratePassword()
{
PasswordRequirements requirements = _repository.GetPasswordRequirements();
[password generation logic here]
}
}
PasswordRequirements.cs
public class PasswordRequirements
{
public int MaxLength { get; set; }
public int NoUpper { get; set; }
public int NoLower { get; set; }
public int NoNumeric { get; set; }
public int NoSpecial { get; set; }
}
How do I decouple the PasswordGenerator? So I don't have to pass to it and I can inject an interface instead which will be used by IoC Container?
1st - Derive an interface:
public class IPasswordRequirements
{
int MaxLength { get; }
int NoUpper { get; }
int NoLower { get; }
int NoNumeric { get; }
int NoSpecial { get; }
}
2nd - Inherit from interface:
public class PasswordRequirements : IPasswordRequirements
{
public int MaxLength { get; set; }
public int NoUpper { get; set; }
public int NoLower { get; set; }
public int NoNumeric { get; set; }
public int NoSpecial { get; set; }
}
3rd - Update constructor:
public class PasswordGenerator : IPasswordGenerator
{
public PasswordGenerator(IPasswordRequirements passwordRequirements)
{
}
That's it.
Don't use a repository here
My fear is that your understanding of a repository and DI infer some time of requirement to always be used together. What I believe your lacking is the code that instantiates dependencies. While a repository may at it's core provide that as a bases of it's pattern, it isn't the correct choice here, because of two reasons; first you aren't storing the items in the repository (that is there is no tier virtual or physical abstraction to wrap the repository around) and secondly you aren't providing generic access to a wide variety of types, just a single one.
At it's core the only thing a repository needs to be useful is a configuration/object to pass objects.. to some other tier (SQL, File system, Web API). A repository is not required in all instances to know anything about how objects are created.
Choose a framework that fits your need
Instead, what you need is a framework built at it's core around DI; object creation and disposal, and having an interface/configuration in which to configure the framework so it can be aware of dependencies to assist in the creation of dependent objects. There are three that come to mind AutoFac, Ninject and Unity. In each of these case, you are in some way, required to configure each type and use it's pattern to create objects. In many cases these Frameworks can even be full featured replacements with other Microsoft Frameworks (MVC for example, has it's own way to instantiate objects, but can be replace with other DI Frameworks). In no way are these frameworks required to know configuration on how to pass these objects to other tiers. It may do so simply by configuration as a by-product, but at it's core that's not what is configured.
For example with Autofac, first you create builder which is basically a fancy way to create a configuration:
var builder = new ContainerBuilder()
Then you register your types:
builder.RegisterType<PasswordRequirements>.As<IPasswordRequirements>();
Create a Container which manages objects: from their instantiation to their configuration.
var container = builder.Build();
Create a scope which defines the duration of an objects lifetime.
using (var scope = new BeginLifetimeScope())
{
// all objects created by scope which be disposed when the scope is diposed.
var passwordRequirements = scope.Resolve<IPasswordRequirements>();
}
By default passwordRequirements will be a new PasswordRequirements(). From there you simply build out your necessary dependency requirements and let the framework handle the rest.
Crux of the issue related to Dependency Inversion
On creating the instance of the PasswordGenerator. which inject, IPasswordRequirementsRepository, in current design there's a limitation of passing the concrete instance of PasswordRequirements, which shall be avoided for true Dependency inversion design.
Following are the possible solutions:
Create an interface or preferably an abstract class for the PasswordRequirements, which can be overridden and can be injected on the need basis, which will be automatically injected when IPasswordRequirementsRepository is injected in the PasswordGenerator
Let's consider the abstract class:
public abstract class BasePasswordRequirements
{
public abstract int MaxLength { get; set; }
public abstract int NoUpper { get; set; }
public abstract int NoLower { get; set; }
public abstract int NoNumeric { get; set; }
public abstract int NoSpecial { get; set; }
}
public class PasswordRequirements : BasePasswordRequirements
{
public override int MaxLength { get; set; }
public override int NoUpper { get; set; }
public override int NoLower { get; set; }
public override int NoNumeric { get; set; }
public override int NoSpecial { get; set; }
}
Using Ninject DI container Binding would be as follows, along with named binding:
Kernel.Bind<IPasswordRequirementsRepository>().To<PasswordRequirementsRepository>()
Kernel.Bind<BasePasswordRequirements>().To<PasswordRequirements>()
PasswordRequirementsRepository will be as follows:
public class PasswordRequirementsRepository : IPasswordRequirementsRepository
{
private readonly BasePasswordRequirements Requirements{get;}
public PasswordRequirementsRepository(BasePasswordRequirements requirements)
{
Requirements = requirements;
}
public BasePasswordRequirements GetPasswordRequirements()
{
return Requirements;
}
}
Another option would be constructor Injection, in that case PasswordRequirements, may not need a Base class or interface, in that case binding would be like:
Kernel.Bind<IPasswordRequirementsRepository>().To<PasswordRequirementsRepository>()
.WithConstructorArgument("requirements", new
PasswordRequirements { .... });
This would call the correct constructor, with relevant values filled in
You may also consider combination of both approached 1 and 2 , where you create a base class / interface for PasswordRequirements and also constructor injection.
For various versions of PasswordRequirements, that you may want to inject consider named binding, following shall be example, instead of:
public class PasswordRequirementsRepository : IPasswordRequirementsRepository
{
private readonly Func<string,BasePasswordRequirements> RequirementsFunc{get;}
public PasswordRequirementsRepository(Func<string,BasePasswordRequirements> requirementsFunc)
{
RequirementsFunc = requirementsFunc;
}
public BasePasswordRequirements GetPasswordRequirements(string name="Version1")
{
return requirementsFunc(name);
}
}
Ninject Binding would be as follows
Kernel.Bind<Func<string,BasePasswordRequirements>>()
.ToMethod(context => name => context.Kernel
.Get<BasePasswordRequirements>(name);
);
Bind<BasePasswordRequirements>().To<PasswordRequirements>().Named("Version1");
Bind<BasePasswordRequirements>().To<AnotherPasswordRequirements>().Named("Version2");
Here the Name for Binding can be passed at the run-time to tweak object that will be injected and thus change the behavior by run-time, thus achieving dependency inversion by using a DI framework like Ninject, which lot of flexible options
Based on the code snippet in your question, the implementation of PasswordGenerator is decoupled from the implementation of the IPasswordRequirementsRepository as it is the interface that is given as constructor argument and not a specific implementation.
To decouple the PasswordRequirementsRepository from a specific implementation of the PasswordRequirements you can do one of two things.
Introduce an interface IPasswordRequirements.
Make PasswordRequirements abstract.
Either approach will decouple the implementation of PasswordRequirementsRepository from the implementation of PasswordRequirements.
DI container
How do I decouple the PasswordGenerator? So I don't have to pass to it
new PasswordRequirementsRepository(new PasswordRequirements{[properties assigned here]})
and I can inject an interface instead which will be used by IoC Container? How can I pass in the data assigned to PasswordRequirements properties to the PasswordGenerator without creating an instance of PasswordRequirementsRepository?
I believe that this part of the question builds on a misunderstanding of the role of the DI container. When building your container you will register all the Classes/Interfaces that is needed in your system. This could look something like the following:
Register<IPasswordRequirements>().To<PasswordRequirements>();
Register<IPasswordRequirementsRepository>().To<PasswordRequirementsRepository>();
Register<IPasswordGenerator>().To<PasswordGenerator>();
After registering everything you can ask the container to provide you with an instance of an interface. In your case, this would be an instance of IPasswordGenerator. The request typically looks a something like this:
var passwordGenerator = contain.Resolve<IPasswordGenerator>();
Normally you only request the topmost component of your program, as the DI container knows what is needed to instantiate every class the component depends on. You would not create a new instance of PasswordGenerator by manually resolving the dependencies and the inject these into the constructor. This approach counteracts the purpose of the DI container.
One option might be to use generics to abstract out the different types of password requirements you might use, and pass the options through the GeneratePassword method since that's really a parameter to how you generate the password. I.E.
interface IPasswordGenerator<TPasswordRequirements>
{
string GeneratePassword(TPasswordRequirements reqs);
}
interface IPasswordRequirementRepository<TPasswordRequirements>
{
TPasswordRequirements GetPasswordRequirements();
}
Implemented by
class DefaultPasswordReqs
{
public int MaxLength { get; set; }
// ...
}
class DefaultPasswordGenerator : IPasswordGenerator<DefaultPasswordReqs>
{
public string GeneratePassword(DefaultPasswordReqs reqs)
{
// ... logic specific to DefaultPasswordReqs
}
}
class InMemoryPasswordRequiremntsRepository<TPasswordRequirements> :
IPasswordRequirementRepository<TPasswordRequirements>
{
private readonly TPasswordRequirements _reqs;
public InMemoryPasswordRequiremntsRepository(TPasswordRequirements reqs)
{
_reqs = reqs;
}
public TPasswordRequirements GetPasswordRequirements()
{
return _reqs;
}
}
And then in whatever code depends on the password generator, have it take a dependency which has the specifc type of password requirements it will use and read the requirements and use those requirements to generate the password.
var requirements = _passwordRequiremntsRepository.GetPasswordRequirements();
var password = _passwordGenerator.GeneratePassword(requirements);
As mentioned in the documentation of Castle.Windsor Framework there should be the possibility to resolve a basic class with properties and resolve dependencies by using property injection. I found no solution and the created solution works only for the basic class/object:
public class Class5
{
public int Id { get; set; }
public string Description { get; set; }
public virtual Class9 Class9 { get; set; }
}
public class Class9
{
public int Id { get; set; }
public string Description { get; set; }
public virtual Class10 Class10 { get; set; }
}
in program:
IWindsorContainer castle = new WindsorContainer();
castle.Register(Castle.MicroKernel.Registration.Component.For(typeof(Class5)));
var obj = castle.Resolve<Class5>();
obj.Description = "Hello Class5"; //works fine
other dependencies are not created:
obj.Class9.Description = "Hello Class9"; // no object instance of Class9 created
Does someone have a solution?
The aim is to create only one basic instance of a class and all other instances will be created automatically. Maybe another IOC Framework is better?
The solution should not contain any interfaces or repositories - only a simple solution for this case for the classes.
I already tried Unity and it works fine with InjectionProperty and [Dependency] - Settings, but with IEnumerables or ICollections it ends up in problems, also all unused objects will be saved in database as null reference by using entity framework(!).
With Castle.Windsor that should also be no problem, but I did not find a solution.
Alternative for Class5 with ICollection:
public class Class5
{
public int Id {get;set;}
public string Description {get;set;}
//public virtual Class9 Class9 {get;set;}
public virtual ICollection<Class9> Class9{get;set;}
}
Windsor cannot create an instance of Class9 because you have not registered it.
As already said here, Castle.Windsor can't create any other class than Class5 because you don't register any other class.
To do this you can do the following:
IWindsorContainer castle = new WindsorContainer();
castle.Register(Component.For<Class5>().LifestyleTransient());
castle.Register(Component.For<Class9>().LifestyleTransient());
Now when you call castle.Resolve<Class5>() you will also get an instance of Class9.
If you have more classes to register, I would recommend you to use an IWindsorInstaller:
public class Bootstrapper
{
public IWindsorContainer BootstrapperContainer()
{
IWindsorContainer castle = new WindsorContainer();
return castle.Install(new Installer());
}
}
public class Installer : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container.Register(Component.For<Class5>().LifestyleTransient());
container.Register(Component.For<Class9>().LifestyleTransient());
//and so on
}
}
Also make sure you use the correct Lifestyle. By default Castle.Windsor uses LifestyleSingleton() which may not be the behaviour you want.
For more information about the available lifestyles check the official documentation.
An interface depends of same type of interface to complete some certain actions. But when I try to register it with unity I am getting
An unhandled exception of type 'System.StackOverflowException'
occurred in Microsoft.Practices.Unity.DLL
I think it falls into a kind of self referencing loop and fills the memory.
Is there something wrong to my approach.
How can I resolve it?
I have interface like this;
public interface IEnvironment
{
string RootUrl { get; set; }
string ImagesPath { get; set; }
IEnvironment DependentEnvironment { get; set; }
}
This is representation of my running code environment such as Localhost, Production, Windows Phone Simulator etc..
I have two classes implementing this right now;
class Localhost : IEnvironment
{
public string RootUrl { get; set; }
public string ImagesPath { get; set; }
public IEnvironment DependentEnvironment { get; set; }
public Localhost(IEnvironment dependentEnvironment)
{
ImagesPath = "images";
DependentEnvironment = dependentEnvironment;
}
}
and
public class WindowsPhoneSimulator : IEnvironment
{
public string RootUrl { get; set; }
public string ImagesPath { get; set; }
public IEnvironment DependentEnvironment { get; set; }
public WindowsPhoneSimulator(IEnvironment dependentEnvironment)
{
ImagesPath = "/Assets/images";
DependentEnvironment = dependentEnvironment;
}
}
so one environment can depend another one? Why? Because for example WindowsPhoneSimulator can make api calls to localhost and when I deploy application I will change injection as ProductionEnvironment. So it should know which environment to call.
The problem begins when I start to resolve my objects like;
IocContainer.RegisterType<IEnvironment, WindowsPhoneSimulator>();
any suggestions?
You haven't shown how you are registering your types, but presumably you are just registering them with a standard RegisterType method. When you register the second type, it will overwrite the first, so Unity only knows about one of your classes (the one that is registered second). Then it makes sense as to why you get a stack overflow exception, because it is trying to create an instance of say, the WindowsPhoneSimulator class to pass into the WindowsPhoneSimulator class...which obviously it can't do.
Instead you will need to register the types in unity as "named types", then when you want to use one of them, you create a dependency override when resolving the class, to tell Unity which one you want to use.
So, register the types as named types:
container.RegisterType<IEnvironment, Localhost>("Localhost")
container.RegisterType<IEnvironment, WindowsPhoneSimulator>("WindowsPhoneSimulator")
Then when you want to create the type, something like this:
DependencyOverride dep = new DependencyOverride(typeof(IEnvironment)
, container.Resolve<IEnvironment>("Localhost"));
IEnvironment obj2 = container.Resolve<IEnvironment>("WindowsPhoneSimulator", dep);
In the above example, you are first resolving the instance of the Localhost class, and then creating the dependencyOverride with that instance, and passing it into the constructor for the WindowsPhoneSimulator class. So, WindowsPhoneSimulator gets passed the instance of Localhost when it is constructed.
I am writing a storage solution for a workflow hierarchy.
To simplify the picture I have 2 types of objects, a Workflow and a WorkflowStep.
Even though WorkflowStep comes hierarchically under the Workflow, the Workflow does not aggregate WorkflowStep because we view these objects as just data containers.
So this leaves me with the following classes:
public class Workflow : Node {
public string UID;
public string parentID;
}
public class WorkflowStep : Node {
public string UID;
public string parentID;
}
public class WorkflowEngine {
public void Store(Workflow wf) {
}
public void Store(WorkflowStep wfs) {
}
}
The reasoning for not aggregating WorkflowStep inside Workflow (even though logically that fits) is that these objects are purely viewed as data containers and they may be subject to changes later on and we want to keep the storage of these objects decoupled from the objects themselves.
The other alternative of course would be to do something like this:
public class Workflow : Node {
public List<WorkflowStep> steps;
public string UID;
public string parentUID;
public void Store() { }
}
public class WorkflowStep : Node {
public string UID;
public string parentID;
public void Store() { }
}
What are the pros and cons of either approach? Is there any literature that talks about both the designs?
Even though Workflow and WorkflowStep are both data containers but keeping these aside from hierarchical measures doesn't solve your decoupling issue.
It is more logical to keep WorkflowStep on hierarchy of Workflow and to get along with decoupling you must introduce IoC in this case.
The Beauty of IoC is that changing the definitions of WorkflowStep which is a list in Workflow class will be just transparent where you will only be considering to register your types on your IoC container.
Let me put you on an example with Ninject IoC container framework.
Define interfaces and implement your data containers accordingly:
public interface IWorkflow {
string UID { get; set; }
string parentID { get; set; }
IList<IWorkflowStep> Steps { get; set; }
}
public interface IWorkflowStep {
string UID { get; set; }
string parentID { get; set; }
}
public class Workflow : IWorkflow, Node {
public string UID { get; set; };
public string parentID { get; set; };
public IList<IWorkflowStep> Steps { get; set; }
}
public class WorkflowStep : IWorkflowStep, Node {
public string UID { get; set; };
public string parentID { get; set; };
}
And now, the Ninject module be:
public class WorkflowModule : NinjectModule
{
#region Overrides of NinjectModule
public override void Load()
{
Bind<IWorkflow>().To<Workflow>();
Bind<IWorkflowStep>().To<WorkflowStep>();
Bind<IList>().To<List>();
}
#endregion
}
This is the single place where you bind your interfaces with concrete classes. And rest of the world, you just ask for an instance of defined interface.
To resolve your type, you need to create a Ninject Kernel which is an IKernel type and a concrete implementation of StandardKernel by loading your defined module.
Which is something like,
var kernel = new StandardKernel(new WorkflowModule());
Now, all you have to do is resolve your desired interface, like:
IWorkflow workflow = kernel.Get<IWorkflow>();
IWorkflowStep workflowStep = kernel.Get<IWorkflowStep>();
The beauty here is, you don't need to worry about your concrete implementation and which is very tightly coupled within your system. Its just the interface you will be dealing with and rest are the worries of your IoC container implementation.
As you are more worried about the implementation of WorkflowStep to be changed and not coupling with Workflow. I guess, this is where IoC comes to play.
Please be noted that, you can use any IoC container framework like Unity, Spring.NET, StructureMap and etc. I used Ninject because I am comfortable with it.