I'm playing around with Caliburn.Micro and have a very simple application now.
It has an AppView, which actually has a ContentControl for a NavigationBar, an InnerView and a StatusBar.
Now I want to handle Navigation between different inner views.
Right now I use the eventaggregator to publish a NavigationEvent, which should
switch the innerview of the mainwindow to another view.
Here is my call to Publish (all InnerViews have the same baseclass which has an IEventAggregator)
public void NavigateOverview()
{
base._eventAggregator.Publish(new NavigateEvent("OverviewViewModel"));
}
Right now I pass a string to the AppViewModel, which handles the NavigateEvent:
public void Handle(NavigateEvent navigate)
{
InnerViewModel target;
switch (navigate.TargetViewModel)
{
case "SelectProjectViewModel":
{
target = new SelectProjectViewModel(_eventAggregator);
break;
}
case "OverviewViewModel":
{
target = new OverviewViewModel(_eventAggregator);
break;
}
default:
{
throw new InvalidOperationException("no target type found");
}
}
this.CurrentInnerViewModel = target;
}
Passing strings works, but is errorprone and not very clean.
What is the Caliburn way of handling that?
Is that what a Conductor should do?
Why not just pass a type instead? That way there are no magic strings
e.g.
public void NavigateOverview()
{
base._eventAggregator.Publish(new NavigateEvent(typeof(OverviewViewModel)));
}
then:
public void Handle(NavigateEvent navigate)
{
InnerViewModel target;
// EDIT: Remove the case (only works with integral types so you can't use typeof etc)
// but you could do this with standard conditional logic
this.CurrentInnerViewModel = target;
}
Edit 2:
Ok since you asked about building into CMs IoC, here is an example for using the IoC with Castle Windsor and a solution for passing additional parameters to navigation (borrowing from EventAggregator)
The bootstrapper just needs a few bits and pieces to config the container:
public class AppBootstrapper : Bootstrapper<ShellViewModel>
{
// The Castle Windsor container
private IWindsorContainer _container;
protected override void Configure()
{
base.Configure();
// Create the container, install from the current assembly (installer code shown in next section below)
_container = new WindsorContainer();
_container.Install(FromAssembly.This());
}
// Matches up with Windsors ResolveAll nicely
protected override IEnumerable<object> GetAllInstances(Type service)
{
return (IEnumerable<object>)_container.ResolveAll(service);
}
// Matches up with Windsors Resolve
protected override object GetInstance(Type service, string key)
{
return string.IsNullOrEmpty(key) ? _container.Resolve(service) : _container.Resolve(key, service);
}
// Windsor doesn't do property injection by default, but it's easy enough to get working:
protected override void BuildUp(object instance)
{
// Get all writable public properties on the instance we will inject into
instance.GetType().GetProperties().Where(property => property.CanWrite && property.PropertyType.IsPublic)
// Make sure we have a matching service type to inject by looking at what's registered in the container
.Where(property => _container.Kernel.HasComponent(property.PropertyType))
// ...and for each one inject the instance
.ForEach(property => property.SetValue(instance, _container.Resolve(property.PropertyType), null));
}
}
The Windsor Installer for CM will probably be as simple as:
public class CaliburnMicroInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
// Register the window manager
container.Register(Component.For<IWindowManager>().ImplementedBy<WindowManager>());
// Register the event aggregator
container.Register(Component.For<IEventAggregator>().ImplementedBy<EventAggregator>());
}
}
I also have a navigation service interface to aid with application navigation:
public interface INavigationService
{
void Navigate(Type viewModelType, object modelParams);
}
Which is implemented by NavigationService (show you that in a sec)
That needs a Windsor installer too:
public class NavigationInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container.Register(Component.For<INavigationService>().ImplementedBy<NavigationService>());
}
}
The NavigationService works much like EventAggregator in that the type that exposes navigation arguments should implement a generic interface for each argument class that it can receive...
The interface looks like this (borrowing heavily from EventAggregator):
// This is just to help with some reflection stuff
public interface IViewModelParams { }
public interface IViewModelParams<T> : IViewModelParams
{
// It contains a single method which will pass arguments to the viewmodel after the nav service has instantiated it from the container
void ProcessParameters(T modelParams);
}
example:
public class ExampleViewModel : Screen,
// We can navigate to this using DefaultNavigationArgs...
IViewModelParams<DefaultNavigationArgs>,
// or SomeNavigationArgs, both of which are nested classes...
IViewModelParams<SomeOtherNavigationArgs>
{
public class DefaultNavigationArgs
{
public string Value { get; private set; }
public DefaultNavigationArgs(string value)
{
Value = value;
}
}
public class OtherNavigationArgs
{
public int Value { get; private set; }
public DefaultNavigationArgs(int value)
{
Value = value;
}
}
public void ProcessParameters(DefaultNavigationArgs modelParams)
{
// Do something with args
DisplayName = modelParams.Value;
}
public void ProcessParameters(OtherNavigationArgs modelParams)
{
// Do something with args. this time they are int!
DisplayName = modelParams.Value.ToString();
}
}
This leads to some strongly typed navigation (e.g. refactor friendly!)
NavigationService.Navigate(typeof(ExampleViewModel), new ExampleViewModel.DefaultNavigationArgs("hello"));
or
NavigationService.Navigate(typeof(ExampleViewModel), new ExampleViewModel.OtherNavigationArgs(15));
It also means that the ViewModel is still in control of it's own navigation parameters
Ok back to Windsor for a sec; obviously we need to install any views from our views namespace - Windsors fluent API makes this pretty easy:
public class ViewInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
// The 'true' here on the InSameNamespaceAs causes windsor to look in all sub namespaces too
container.Register(Classes.FromThisAssembly().InSameNamespaceAs<ShellViewModel>(true));
}
}
Ok now the NavigationService implementation:
public class NavigationService : INavigationService
{
// Depends on the aggregator - this is how the shell or any interested VMs will receive
// notifications that the user wants to navigate to someplace else
private IEventAggregator _aggregator;
public NavigationService(IEventAggregator aggregator)
{
_aggregator = aggregator;
}
// And the navigate method goes:
public void Navigate(Type viewModelType, object modelParams)
{
// Resolve the viewmodel type from the container
var viewModel = IoC.GetInstance(viewModelType, null);
// Inject any props by passing through IoC buildup
IoC.BuildUp(viewModel);
// Check if the viewmodel implements IViewModelParams and call accordingly
var interfaces = viewModel.GetType().GetInterfaces()
.Where(x => typeof(IViewModelParams).IsAssignableFrom(x) && x.IsGenericType);
// Loop through interfaces and find one that matches the generic signature based on modelParams...
foreach (var #interface in interfaces)
{
var type = #interface.GetGenericArguments()[0];
var method = #interface.GetMethod("ProcessParameters");
if (type.IsAssignableFrom(modelParams.GetType()))
{
// If we found one, invoke the method to run ProcessParameters(modelParams)
method.Invoke(viewModel, new object[] { modelParams });
}
}
// Publish an aggregator event to let the shell/other VMs know to change their active view
_aggregator.Publish(new NavigationEventMessage(viewModel));
}
}
Now the shell can just handle the aggregator message and activate the new injected and additionally configured VM
public class ShellViewModel : Conductor<IScreen>, IHandle<NavigationEventMessage>
{
private IEventAggregator _aggregator;
private INavigationService _navigationService;
public ShellViewModel(IEventAggregator aggregator, INavigationService _navigationService)
{
_aggregator = aggregator;
_aggregator.Subscribe(this);
_navigationService.Navigate(typeof (OneSubViewModel), null);
}
public void Handle(NavigationEventMessage message)
{
ActivateItem(message.ViewModel);
}
}
Actually I constrain the navigation to just IScreen implementations so my NavigationEventMessage actually looks like this:
public class NavigationEventMessage
{
public IScreen ViewModel { get; private set; }
public NavigationEventMessage(IScreen viewModel)
{
ViewModel = viewModel;
}
}
This is because I always want lifecycle for my child viewmodels
Related
TL;DR. I have a circular dependency and no idea how to break it.
Main.csproj: has Program.cs which manually instantiates DiService
var diService = new DiService(new Container());
diService.Register();
The register method searches CurrentDomain for assemblies and registers collections where multiple implementations exist for a given interface or else registers concretions on a 1-1 basis.
It then uses the Container to instantiate an abstract factory.
var diFactory = diService.Registry.GetInstance<IDiFactory>();
Here's the factory
public class DiFactory : IDiFactory
{
private readonly Container registry;
public DiFactory(Container registry)
{
this.registry = registry;
}
public T Get<T>()
{
var reqT = typeof(T);
return (T) registry.GetInstance(reqT);
}
}
The project dependencies in the solution look like this:
Main -> A -> B,E
B -> C,D,E
C -> D,E
D -> E
DiService and DiFactory live in project B with the other services. Not that it matters. I think I'd have the same problem if they were in Main.
All objects in projects B to E have a constructor injected DiFactory so they can decide what objects they need at run time. But for C to make use of it, it must depend on B, which is a circular dependency.
If I move the DI stuff to a new project F, then all projects can depend on that but how does the factory reference the types in the other projects without creating another circular dependency?
I followed the documentation for IRequestHandler, I just didn't do the dictionary. Most likely I have a design flaw but I can't see what it is.
Here's an example of the interactions between objects for LinqPad - doesn't compile but it looks right.
void Main()
{
var diService = new Mine.Services.MyDiService();
var diFactory = diService.Container.GetInstance<Mine.Services.IMyFactory>();
var rand = new Random();
var next = rand.Next(1, 100);
var task = next % 2 == 0
? diFactory.Get<Mine.Tasks.EvenTask>()
: (Mine.Tasks.IMyTask)diFactory.Get<Mine.Tasks.OddTask>();
task.Perform();
}
namespace Mine.Common
{
public class MyCommonObject { }
}
namespace Mine.Services
{
public class FakeContainer
{
public T GetInstance<T>() { return default(T); }
}
public interface IMyOtherService { void DoSomethingElse(); }
public class MyOtherService : IMyOtherService
{
public void DoSomethingElse()
{
throw new NotImplementedException();
}
}
public class MyService
{
private readonly IMyFactory myFactory;
public MyService(IMyFactory myFactory)
{
this.myFactory = myFactory;
}
public void MyServiceMethod()
{
var thing = myFactory.Get<Mine.Common.MyCommonObject>();
}
}
public interface IMyFactory { T Get<T>(); }
public class MyDiService
{
public FakeContainer Container;
}
public class MyFactory : IMyFactory
{
private FakeContainer Container;
public MyFactory(FakeContainer container)
{
// obviously this is really a SImple Injector Container
Container = container;
}
public T Get<T>()
{
return default(T);
}
}
}
namespace Mine.Kernel {
public interface IMyMultiConcrete { void Do(); }
public class MyConcreteBase : IMyMultiConcrete
{
protected readonly Mine.Services.IMyFactory MyFactory;
public MyConcreteBase(Mine.Services.IMyFactory myFactory)
{
MyFactory = myFactory;
}
public void Do()
{
MyFactory.Get<Mine.Common.MyCommonObject>();
}
}
public class MyConcrete1 : MyConcreteBase
{
public MyConcrete1(Mine.Services.IMyFactory myFactory) : base(myFactory) {}
public void Do()
{
MyFactory.Get<Mine.Common.MyCommonObject>();
}
}
}
namespace Mine.Tasks
{
public interface IMyTask { void Perform(); }
public class TaskBase : IMyTask
{
protected readonly Mine.Services.IMyOtherService MyOtherService;
public TaskBase(Mine.Services.IMyFactory myFactory, Mine.Services.IMyOtherService myOtherService)
{
MyOtherService = myOtherService;
}
public void Perform()
{
MyOtherService.DoSomethingElse();
}
}
public class OddTask : TaskBase
{
public OddTask(Mine.Services.IMyFactory myFactory, Mine.Services.IMyOtherService myOtherService)
: base(myFactory, myOtherService) { }
}
public class EvenTask : TaskBase
{
public EvenTask(Mine.Services.IMyFactory myFactory, Mine.Services.IMyOtherService myOtherService)
: base(myFactory, myOtherService) { }
}
}
This IDiFactory abstraction you are describing is not an implementation of the Abstract Factory design pattern—it is an implementation of the Service Locator pattern. Service Locator, however, is an anti-pattern and you should stop using it because its numerous downsides.
Instead, classes should not be able to request an unbound set of dependencies from a Service Locator, but neither should they typically be able to request a fixed set of dependencies using an Abstract Factory. Instead, classes should statically declare their required dependencies through the constructor.
This change might already fix the circular dependency as you will remove the IDiFactory (that is causing the cycle) in the first place.
DiService and DiFactory live in project B with the other services. Not that it matters.
It does matter where you wire up your dependencies. Dependencies should be wired up in your Composition Root and this Composition Root should live
As close as possible to the application’s entry point.
This most likely means that you should move this to your Console application. When you move that code, only the start-up assembly will take a dependency on the used DI Container. At that point, it becomes irrelevant to hide the DI Container behind an Abstraction (as your DiService seems to imply). Hiding is not needed anymore, because no other parts of the application except the Composition Root will have any knowledge about how dependency graphs are built. Hiding the DI Container behind an abstraction, at that point, doesn't increase maintainability any longer.
There might be an easier way, but what I typically end up doing is to have a separate assembly containing interfaces for everything I need to inject.
The main assembly (or B could do it in your case) performs the binding of interfaces to concrete implementations and everyone can reference the interfaces assembly without creating any circular dependencies.
The interface for the factory should also be in that assembly.
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.
I have generic factory
public interface IViewModelFactory<T> where T : IViewModel
{
T Create<TU>(TU par);
}
public class ViewModelFactory<T> : IViewModelFactory<T> where T : IViewModel
{
private readonly ILifetimeScope _scope;
public ViewModelFactory(ILifetimeScope scope)
{
_scope = scope;
}
public T Create<TU>(TU par)
{
return _scope.Resolve<T>(new TypedParameter(typeof(TU), par));
}
}
which I can use for resolving viewmodel factory in my window class:
public WRPersons(IViewModelFactory<MRPersons> viewModelFactory)
{
var viewModel = viewModelFactory.Create(new MRPersonsUseCaseParams { Filter = 2 });
...
}
ViewModel is implemented by following code
public class MRPersons : IViewModel
{
public MRPersons(MRPersonsUseCaseParams par)
{
_filter = par.Filter;
}
}
public class MRPersonsUseCaseParams
{
public int Filter { get; set; }
}
Registration in my composition root looks like:
var builder = new ContainerBuilder();
builder.RegisterType<ViewModelFactory<MRPersons>>().As<IViewModelFactory<MRPersons>>();
builder.RegisterType<MRPersons>();
As you can see for each new ViewModel (now its only MRPerson) I will need to create two entries into my composition root. Thus for MRCar it will be:
builder.RegisterType<ViewModelFactory<MRCar>>().As<IViewModelFactory<MRCar>>();
builder.RegisterType<MRCar>();
I would like to automatize these registration somehow. I experimented with RegisterAssemblyTypes/AsClosedTypesOf but without success. Can somebody help me?
EDIT:
Based on answer codeline
builder.RegisterType<ViewModelFactory<MRPersons>>().As<IViewModelFactory<MRPersons>>();
is replaced by
builder.RegisterGeneric(typeof(ViewModelFactory<>)).As(typeof(IViewModelFactory<>));
Full automatic registration looks like:
builder.RegisterAssemblyTypes(Assembly.GetEntryAssembly()).Where(x => iViewModelType.IsAssignableFrom(x) && x.IsClass).AsSelf();
builder.RegisterGeneric(typeof(ViewModelFactory<>)).As(typeof(IViewModelFactory<>));
For better testable solution it would be fine to even replace MRPersons by IMRPersons:
public class MRPersons : IViewModel, IMRPersons
{
public MRPersons(MRPersonsUseCaseParams par)
{
_filter = par.Filter;
}
}
public class MRPersonsUseCaseParams
{
public int Filter { get; set; }
}
public interface IMRPersons
{
}
Thus registration in composition root would looks like (NEED TO BE CORRECTED)
builder.RegisterAssemblyTypes(Assembly.GetEntryAssembly()).Where(x => iViewModelType.IsAssignableFrom(x) && x.IsClass).As<??????>.AsSelf();
This would allows me to pass factory into constructor in following way:
public WRPersons(IViewModelFactory<IMRPersons> viewModelFactory)
{
var viewModel = viewModelFactory.Create(new MRPersonsUseCaseParams { Filter = 2 });
...
}
EDIT2:
During chat with Cyril Durand he provided solution for ViewModelFactory without reference to ILifetimeScope. Here is a code:
public interface IViewModelFactory2<T, TU> where T : IViewModel
{
T Create(TU par);
}
public class ViewModelFactory2<T, TU> : IViewModelFactory2<T, TU> where T : IViewModel
{
private readonly Func<TU, T> _factory;
public ViewModelFactory2(Func<TU, T> factory)
{
_factory = factory;
}
public T Create(TU par)
{
return _factory(par);
}
}
My original factory is Ok too since it is presented in composition root where strong references to DI container can be used.
You want to register ViewModelFactory<> as IViewModelFactory<>, you can do it using the RegisterGeneric method.
builder.RegisterGeneric(typeof(ViewModelFactory<>)).As(typeof(IViewModelFactory<>));
Then you will be able to resolve IViewModelFactory<MRCar> without any other registration.
See Registration Concepts - Open Generic Components for more information
For the second part of the question :
For better testable solution it would be fine to even replace MRPersons by IMRPersons
It is not so easy because there is no way to know which interface to use. You can use the AsImplementedInterfaces which will be equivalent to As<IMRPersons>().As<IViewModel>() but it may be a problem if you have a lot of implemented interface.
builder.RegisterAssemblyTypes(Assembly.GetEntryAssembly())
.Where(x => iViewModelType.IsAssignableFrom(x) && x.IsClass)
.AsImplementedInterfaces();
Or you can use a convention that will register all X asIX but I'm not a big fan of this kind of registration.
builder.RegisterAssemblyTypes(Assembly.GetExecutingAssembly())
.Where(x => iViewModelType.IsAssignableFrom(x) && x.IsClass)
.As(t => t.GetInterfaces().Where(i => i.Name.EndsWith(t.Name)));
By the way, after chatting, we figured out that you don't need a IViewModelFactory<> at all but you only need a dependency on Func<TParam, T>
I have a class, which contain my actions (any logic):
public class socActions
{
public void Choose(int elem)
{
switch(elem) ... CalcA(elem) || CalcB(elem) ...
}
public void CalcA()
{
}
public void CalcB()
{
}
public void CalcC()
{
}
}
So, in my program, when i get elem value, i use it like:
(new socActions()).Choose(elem_val);
Okey, but in socActions class methods, i'd like to have a connection with my repository or make any other dependency injection.
If i add IRepositoryMy repositoryMy to constructor, then i couldn't
create classes as above, bcz its need now constructor with argument
IRepositoryMy.
If i try to make injection in field, it doesn't work
(property = null).
If i try to make injection in methods (CalcA,
CalcB) it doesn't work too.
How i really should make this task (inject class, for example repository)? Don't want to mark everything in my application as static :(
WinForms, C#, Ninject 3
Edit:
public class socActions
{
[Inject]
public IGridProcessor _GridProcessor { private get; set; }
so, in method its null:
public void UpdateInfo(...)
{
...
this._GridProcessor.Refresh();
}
In other classes, where i inject IGridProcessor to class in constructor, everything fine.
In Program.cs:
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
var kernel = new StandardKernel(new TwttModule());
var form = kernel.Get<Main>();
Application.Run(form);
}
public class TwttModule : NinjectModule
{
public override void Load()
{
Bind<IGridProcessor>().To<GridProcessor>();
}
}
public static class AnyClass
{
public static void Act()
{
....
(new socActions()).Choose(elem_val);
}
}
How should i inject IGridProcessor to socActions?
When using constructor injection, you don't construct your classes directly, but rather ask ninject for an instance. Based on how you've configured ninject, you get a new instance, or a singleton instance, etc.
From their docs:
Samurai warrior = kernel.Get<Samurai>();
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