is right to implement a business logic in the type binding DI framwork?

Posted by Martino on Stack Overflow See other posts from Stack Overflow or by Martino
Published on 2013-08-02T10:34:26Z Indexed on 2013/08/02 15:37 UTC
Read the original article Hit count: 197

public IRedirect FactoryStrategyRedirect()
{
  if (_PasswordExpired) {
    return _UpdatePasswordRedirectorFactory.Create();
  } else {
    return _DefaultRedirectorFactory.Create();
  }
}

This strategy factory method can be replaced with type binding and when clause:

Bind<IRedirect>.To<UpdatePasswordRedirector>.When(c=> c.kernel.get<SomeContext>().PasswordExpired()) 
Bind<IRedirect>.To<DefaultRedirector>.When(c=> not c.kernel.get<SomeContext>().PasswordExpired())

I wonder which of the two approaches is the more correct. What are the pros and cons.

Especially in the case in which the logic is more complex with more variables to test and more concrete classes to return.

is right to implement a business logic in the binding?

© Stack Overflow or respective owner

Related posts about dependency-injection

Related posts about ninject