We Keep Coding

What are the benefits of using a dependency resolver may be Ninject than using some conditional statement to resolve dependency

Hello first of all I'm just a newbie programmer, I just discovered how dependency injection pattern works and it is used to make my code more loosely coupled. I don't specifically know how to configure a Ninject to resolve the dependency, is it better to use these plug in?
Currently my approach when resolving dependency is like this.
public class MyClass
{
IContract _contract = null;
MyClass()
{
}
MyClass(IContract contract)
{
_contract = contract;
}
public void DoSomething()
{
IContract concreteImplementation = _contract ?? new ConcreteContract();
concreteImplementation.MyMethod();
}
}
public class ConcreteContract : IContract
{
public void MyMethod()
{
//do something;
}
}
public interface IContract
{
void MyMethod();
}

Edward...
I thought I'd add a little detail to my comment. The benefits of DI are as you mention (looser coupling). Also, it allows you to register your contract at both compile and runtime, depending on your requirement. As a result, you can add new implementations without breaking the class that you wish to resolve against.
You'll need a slight refactor to accomplish your goal using Unity. Below is a small self contained example (console app), using your class definitions (and showing an alternative implementation):
public class MyClass
{
readonly IContract _contract = null;
// do not include a paramterless ctor
// thus preventing class being created
// without a concrete implementation of IContract
public MyClass(IContract contract)
{
_contract = contract;
}
public void DoSomething()
{
_contract.MyMethod();
}
}
public class ConcreteContract : IContract
{
public ConcreteContract() { }
public void MyMethod()
{
//do something;
Debug.Print("Hello from the ConcreteContract class");
}
}
public class PlasticContract : IContract
{
public PlasticContract() { }
public void MyMethod()
{
//do something;
Debug.Print("Hello from the PlasticContract class");
}
}
public interface IContract
{
void MyMethod();
}
class Program
{
// add the nuget package Unity 1st
// Install-Package Unity
static void Main(string[] args)
{
// Declare a Unity Container -
// normally done once in the Startup/Bootstrap class
var unityContainer = new UnityContainer();
// Register IContract so when dependecy is detected
// it provides a ConcreteContract instance
// you could change this to <IContract, PlasticContract>
unityContainer.RegisterType<IContract, ConcreteContract>();
// Instance a MyClass class object through Unity
var preferredClass = unityContainer.Resolve<MyClass>();
preferredClass.DoSomething();
}
}
Hope this gets you to the next stage.

Unity resolving nested constructors

I am having two interfaces like ICustomerRepository, IBalanceRepository which are implemented by CustomerRepository.cs and BalanceRepository. Now for entry i have customerservice.cs with constuctor accepting instance of ICustomerRepository. I am calling a method from customerservice.cs to BalanceService.cs which is having constructor accepting instance of IBalancerepository. I registered all classes using unity and resolved customer service, this is resolving ICustomerRespository but not IBalanceRepository. Can we resolve IBalanceRepository repository like this or not? See below code and suggest a solution.
public interface ICusotmerRepository
{
void Add(string strCustomer);
}
public interface IBalanceRepository
{
void Add(decimal decAmount);
}
class CusotmerRepository : ICusotmerRepository
{
public void Add(string strCustomer)
{
Console.WriteLine("Added customer "+strCustomer);
}
}
class BalanceRepository : IBalanceRepository
{
public void Add(decimal decAmount)
{
Console.WriteLine("added amount "+decAmount);
}
}
public class BalanceService
{
private readonly IBalanceRepository _balanceRepository;
public BalanceService(IBalanceRepository balanceRepository)
{
_balanceRepository = balanceRepository;
}
public BalanceService()
{
}
public void AddBalance(decimal decBalance)
{
_balanceRepository.Add(decBalance);
}
}
class CustomerService
{
private readonly ICusotmerRepository _cusotmerRepository;
public CustomerService(ICusotmerRepository cusotmerRepository)
{
_cusotmerRepository = cusotmerRepository;
}
public void Process(string strCustomerName, decimal decBalance)
{
_cusotmerRepository.Add(strCustomerName);
var objBalanceService = new BalanceService();
objBalanceService.AddBalance(decBalance);
}
}
class Program
{
static void Main(string[] args)
{
var container = new UnityContainer();
container.RegisterType<IBalanceRepository, BalanceRepository>();
container.RegisterType<ICusotmerRepository, CusotmerRepository>();
var customerService = container.Resolve<CustomerService>();
customerService.Process("Ganesha",7);
}
}

The problem is here:
public void Process(string strCustomerName, decimal decBalance)
{
_cusotmerRepository.Add(strCustomerName);
var objBalanceService = new BalanceService(); <------------
objBalanceService.AddBalance(decBalance);
}
You are calling the parameterless constructor directly - there's nowhere for Unity to "inject" the dependency into BalanceService.
I see three possibilities:
Add a constructor parameter to CustomerService for BalanceService and let Unity inject it
Add a constructor parameter to CustomerService for IBalanceRepository and let Unity inject it, passing it in when you construct BalanceService
Add IBalanceRepository or BalanceService as a parameter to Process

You can't resolve BalanceService in this way because Unity will not be able to know when you need to resolve this dependency.
You can inject BalanceService into customer service through constructor parameter.

c# constructor vs initialize

Doing TDD and want to isolate the method under test: Direct();
However, when the test creates MyClass, SomeClass.SetupStuff(); blows up (NotImplementedException). So, modified the IMyClass interface to have a Configure(); method that can be called after MyClass construction to avoid the exception.
Question: Is this an accepted way of handling this scenario or is there some basic OOP principal that this breaks?
public class MyClass : IMyClass
{
public MyClass()
{
// class with static method that sets stuff up
SomeClass.SetupStuff();
}
public void IMyClass.Direct()
{
// want to test this
}
}
vs
public class MyClass : IMyClass
{
public MyClass()
{
}
public void IMyClass.Direct()
{
// want to test this
}
//
public void IMyClass.Configure()
{
// class with static method that sets stuff up
SomeClass.SetupStuff();
}
}

One way to avoid such problems is to use dependency injection
public class MyClass : IMyClass
{
public MyClass(ISomeClass someClass)
{
someClass.SetupStuff();
}
public void IMyClass.Direct()
{
// want to test this
}
}
By decoupling your class from SomeClass, you are free to provide a mock implementation of ISomeClass during test and can provide a full implementation at runtime.

Is this still a factory method?

What if I don't need a special factory class and I want a concrete client to instantiate right parts. The client needs to call Hello() from that part. Everywhere else the focus is on making the factory method a method of a special creator class. But here it is right away in a client. Is this still a factory method pattern and is it even correct to use it as shown below?
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
AClient c1 = new ClientUsingPart1();
c1.Foo();
AClient c2 = new ClientUsingPart2();
c2.Foo();
Console.ReadKey();
}
}
abstract class AClient
{
public AClient() { this.ipart = Create(); }
public void Foo() { ipart.Hello(); }
// many other methods
// ...
public abstract IPart Create(); // factory method
IPart ipart;
}
class ClientUsingPart1 : AClient
{
public override IPart Create() { return new Part1(); }
}
class ClientUsingPart2 : AClient
{
public override IPart Create() { return new Part2(); }
}
interface IPart
{
void Hello();
}
class Part1 : IPart
{
public void Hello() { Console.WriteLine("hello from part1"); }
}
class Part2 : IPart
{
public void Hello() { Console.WriteLine("hello from part2"); }
}
}

Depending on exactly what you need to achieve you should probably use some for of dependency injection with an IoC container of your choice; with StructureMap, Autofac, Unit, Ninject, Castle Windsor all very popular. Once you IoC container has built the concrete classes it should support a syntax like this
foreach (var client in Container.Resolve<IEnumerable<AClient>>())
{
client.Create();
}
You can read more about how to achieve this with StructureMap here: Does an abstract class work with StructureMap like an interface does?

According to this:
Differences between Abstract Factory Pattern and Factory Method
It seems the code I posted in the original post shows a valid use of the factory method pattern. The key is - factory method is just a method of the class - which also may be the sole client of the created objects.
Or in another way: factory method does not need to be public and provide the created objects to the outside world. In my example the Create() method should be protected.

Inject same DataContext instance across several types with Unity

Suppose I have IRepository interface and its implementation SqlRepository that takes as an argument LINQ to SQL DataContext. Suppose as well that I have IService interface and its implementation Services that takes three IRepository, IRepository and IRepository. Demo code is below:
public interface IRepository<T> { }
public class SqlRepository<T> : IRepository<T>
{
public SqlRepository(DataContext dc) { ... }
}
public interface IService<T> { }
public class Service<T,T1,T2,T3> : IService<T>
{
public Service(IRepository<T1> r1, IRepository<T2>, IRepository<T3>) { ... }
}
Is it any way while creating Service class to inject all three repositories with the same DataContext?

All you need to do is make sure when you register the Datacontext with your Unity container use the PerResolveLifetimeManager either in config:
<type type="<namespace>.DataContext, <assembly>">
<lifetime type="Microsoft.Practices.Unity.PerResolveLifetimeManager, Microsoft.Practices.Unity" />
</type>
or in code:
container.RegisterType<DataContext>(new PerResolveLifetimeManager());
then whenever the container resolves the Service any dependencies which also require a DataContext will be provided with exactly the same one. But the next request to resolve Service will create a new DataContext.

I think I know what you want to do. I'm in the same boat and am trying to come up with a solution.
My Service layer performs operations on in coming requests, and what it does depends on the contents. It passes it to a series of chain of responsibility classes. I want the same context passed to all classes within the lifetime of the service method called
You can Specify PerResolveLifetimeManager. So far, it seems to be working with my test cases:
Service Class:
public interface IServiceClass
{
void DoService();
}
class ServiceClass : IServiceClass
{
private IHandler Handler { get; set; }
public ServiceClass(IHandler handler)
{
Handler = handler;
}
public void DoService()
{
Handler.HandleRequest();
}
}
IHandler is implemented by two classes, and performs Chain of Responsibility pattern:
public interface IHandler
{
void HandleRequest();
}
class Handler : IHandler
{
private IDataContext DataContext { get; set; }
public Handler(IDataContext dataContext)
{
DataContext = dataContext;
}
public void HandleRequest()
{
DataContext.Save("From Handler 1");
}
}
class Handler2 : IHandler
{
private IDataContext DataContext { get; set; }
private IHandler NextHandler { get; set; }
public Handler2(IDataContext dataContext, IHandler handler)
{
DataContext = dataContext;
NextHandler = handler;
}
public void HandleRequest()
{
if (NextHandler != null)
NextHandler.HandleRequest();
DataContext.Save("From Handler 2");
}
}
As you can see, both handlers accept an instance of IDataContext, which I want to be the same in both of them. Handler2 also accepts an instance of IHandler to pass control to (it does both here to demonstrate, but actually, only one would handle the request...)
IDataContext. In the constructor I initialize a Guid, and during its operation, output it so I can see if both times its called is using the same instance:
public interface IDataContext
{
void Save(string fromHandler);
}
class DataContext : IDataContext
{
private readonly Guid _guid;
public DataContext()
{
_guid = Guid.NewGuid();
}
public void Save(string fromHandler)
{
Console.Out.WriteLine("GUI: [{0}] {1}", _guid, fromHandler);
}
}
Finally, registration and calling of service:
private IUnityContainer container;
private void InitializeUnity()
{
container = new UnityContainer();
container.RegisterType<IHandler, Handler2>("Handler2",
new InjectionConstructor(new ResolvedParameter<IDataContext>(), new ResolvedParameter<IHandler>("Handler1")));
container.RegisterType<IHandler, Handler>("Handler1");
container.RegisterType<IDataContext, DataContext>(new PerResolveLifetimeManager());
container.RegisterType<IServiceClass, ServiceClass>("MyClass", new InjectionConstructor(new ResolvedParameter<IHandler>("Handler2")));
}
private void CallService()
{
var service = container.Resolve<ServiceClass>("MyClass");
service.DoService();
// Resolving and calling again to simulate multiple resolves:
service = container.Resolve<ServiceClass>("MyClass");
service.DoService();
}
This is the output I get:
GUI: [f2250055-8a5f-4f80-a1b6-bcc5574138cf] From Handler 1
GUI: [f2250055-8a5f-4f80-a1b6-bcc5574138cf] From Handler 2
GUI: [22a5c0a3-3c5c-4683-807d-bf2b43f3cd0a] From Handler 1
GUI: [22a5c0a3-3c5c-4683-807d-bf2b43f3cd0a] From Handler 2
Hope this wall of text answered your question... If not sorry, it did inspire a solution I needed to implement...

If I understand your question correctly (and if you are using unity...I suppose you do because you have taggged it with unity) you could do something like this:
In your repository implementions,
[InjectionConstructor]
public SqlRepository(
[Dependency] DataContext ctx)
but then you have to mark the service contructor in the same manner and use the container to resolve your services as well as the repository. The DataContext also has to be in the container to make it work.
An alternative approach is to do something like this with your repository:
[InjectionMethod]
public void Initialize(
[Dependency] DataContext ctx
this will tell unity to call this method if you will, in your service constructor, use unity with the BuildUp method...something like this:
unitycontainer.BuildUp<IRepository>(repository);
I guess that´s not quite what your looking for but please tell me if I´m on the right track and I´ll see if I can help you further...
Cheers / J

Have you tried using the RegisterInstance() method for the unity container? Something like this might work:
public static UnityContainer CreateContainer()
{
UnityContainer container = new UnityContainer();
try
{
var section = ConfigurationManager.GetSection("unity") as UnityConfigurationSection;
if (section != null)
{
section.Containers[0].Configure(container);
}
}
catch (Exception ex)
{
TraceLogger.LogMessage("Configurarion Error for Unity Container", ex.Message, TraceEventType.Critical);
Environment.Exit(1);
}
container.RegisterInstance(new DataContext());
return container;
}
Now, every time this container tries to build an object which needs a DataContext, the same instance will be passed. You could even configure the DataContext before registering its instance.
UPDATE:
One option (now, I don't know if its really a good practice, but this worked for me) is to create a different container for each object you're gonna create. Something like:
UnityContainer container1 = ContainerFactory.CreateContainer();
UnityContainer container2 = ContainerFactory.CreateContainer();
UnityContainer container3 = ContainerFactory.CreateContainer();
MyObject1 object1 = container1.Resolve<MyObject1>();
MyObject2 object2 = container2.Resolve<MyObject2>();
MyObject3 object3 = container3.Resolve<MyObject3>();
or a more summarized way:
MyObject1 object1 = ContainerFactory.CreateContainer().Resolve<MyObject1>();
MyObject1 object2 = ContainerFactory.CreateContainer().Resolve<MyObject2>();
MyObject1 object3 = ContainerFactory.CreateContainer().Resolve<MyObject3>();
Well, there's a lot of ways to do it, creating a list, using the factory pattern. Hope it helps