I have the following class declaration and unit test:
public class Blah { }
[TestMethod]
public void TestMethod1()
{
var container = new Container();
var instance1 = container.GetInstance<Blah>();
var instance2 = container.GetInstance<Blah>();
var areBothInstancesSame = instance1 == instance2;
var nested = container.GetNestedContainer();
var nestedInstance1 = nested.GetInstance<Blah>();
var nestedInstance2 = nested.GetInstance<Blah>();
var areBothNestedInstancesSame = nestedInstance1 == nestedInstance2;
}
When I run this test, areBothInstancesSame is false but areBothNestedInstancesSame is true.
I also tested this inside a Web Api controller action:
public class Blah { }
public IHttpActionResult GetBlah()
{
var scope = this.Request.GetDependencyScope();
var instance1 = (Blah)scope.GetService(typeof(Blah));
var instance2 = (Blah)scope.GetService(typeof(Blah));
var areBothInstancesSame = instance1 == instance2;
return this.Ok();
}
And again, areBothInstancesSame is true.
I see this described in Structuremap's documentation, so I believe it's working as intended, but I don't understand why this is intended or how to get the nested container that Web Api automatically creates to return a new instance for each service with a Transient lifecycle.
Can anyone help me understand: 1) why this is the intended default behavior and how to make the nested container return a new instance every time; or 2) why it's obvious that I should never want the nested container to return a new instance every time?
Thanks
The best answer I can give is that the word nested refers rather to container's services and not necessarily to container hierarchy as it may seem (that is why child containers exist also)
Getting a service instance from a normal container will create a new instance along with the full object graph, with all required nested services inside. No mater how may times some transient service is nested inside the object graph, only one instance is created for that service type and reused within the entire graph.
For a nested container the transient instances behave as they belong to(are nested inside) the same object graph because it's purpose is to be used within one logical request.
maybe this example will help with the usage of nested containers http://structuremap.github.io/the-container/nested-containers/#sec5
basically nested containers exist to ensure transient services will not get a new instance with each GetService call.
To make a nested container return a new instance every time you should register the service as AlwaysUnique
Related
I'm trying to add a test to an ASP.NET Core project where an object is created in one scope and then read in another scope. This is to simulate a user creating an object in one POST request and then reading it in another GET Request. However, I'm having trouble properly simulating this scenario.
I have this in my test code
SomeDbContext firstContext;
bool isSame;
using (var scope = someServiceProvider.CreateScope()) {
firstContext = someServiceProvider.GetService<SomeDbContext>();
}
using (var scope = someServiceProvider.CreateScope()) {
var secondContext = someServiceProvider.GetService<SomeDbContext>();
isSame = firstContext == secondContext; //should be false, right?
}
I expect isSame to have a value of false when the code above executes but it's actually true. Why is that? SomeDbContext has a lifetime of scoped when registering it with AddDbContext() so it should be destroyed when its scope is disposed and recreated in the second scope.
Your test is incorrect. Although you are creating two separate scopes, you're not actually using them. Here's a working version:
SomeDbContext firstContext;
bool isSame;
using (var scope = someServiceProvider.CreateScope()) {
firstContext = scope.ServiceProvider.GetService<SomeDbContext>();
}
using (var scope = someServiceProvider.CreateScope()) {
var secondContext = scope.ServiceProvider.GetService<SomeDbContext>();
isSame = firstContext == secondContext; //should be false, right?
}
Note how scope.ServiceProvider is used instead of someServiceProvider when resolving dependencies.
The closest thing I can find in the docs is Call services from main. Although the example shows the Main method, it does also demonstrate how the IServiceProvider that gets used comes from the scope itself.
At first I did confidentially suppose that I could understand it, but via some simple example with Autofac, it appeared that I might understand it wrong, here is the code that I've tried:
//register the service
autofacBuilder.RegisterType<MyService>()
.As<IMyService>().InstancePerLifetimeScope();
//testing code
void _test1()
{
var myService = autofacContainer.Resolve<IMyService>();
}
void _test2()
{
_test1();
var myService = autofacContainer.Resolve<IMyService>();
}
Test it by running _test2() and you can simply check the instances resolved in the 2 methods.
So with the code above, I understand the myService in _test1 and myService in _test2 should be different. Because I think the lifetime scope of myService in _test1 should be just in that method while the lifetime scope of myService in _test2 should be in _test2 as well. So we have 2 different scopes here, but somehow the resolved instances of myService are the same one.
So could you please explain that issue to me, what does lifetime scope exactly mean here? inside one same class? or something even larger?
You're confusing c# scopes and autofac's scopes. It's like comparing apples and a fence. :) They are just different and have nothing to do with each other.
So, to clarify it please look at basic examples below. Please pay attention that the scopes should actually be destroyed by you if you are the one who started them as it is done in example 1. In other examples I skipped that for brevity.
// example 1
autofacBuilder.RegisterType<MyService>().As<IMyService>().InstancePerLifetimeScope();
var container = autofacBuilder.Build();
void _test1(IComponentContext scope){
var myService = scope.Resolve<IMyService>();
}
void _test2(IComponentContext scope){
// the same scope is used here and in _test1()
// this means that the service instance will be the same here and there
_test1(scope);
var myService = scope.Resolve<IMyService>();
}
// it's only here that DI lifetime scope starts
using (var scope = container.BeginLifetimeScope()) {
_test2(scope);
}
// example 2
autofacBuilder.RegisterType<MyService>().As<IMyService>().InstancePerLifetimeScope();
var container = autofacBuilder.Build();
void _test1(IComponentContext scope){
var myService = scope.Resolve<IMyService>();
}
void _test2(IComponentContext scope){
// now new scope is used in _test1() call
// this means that instances will be different here and there since they are resolved from different scopes
_test1(scope.BeginLifetimeScope());
var myService = scope.Resolve<IMyService>();
}
var scope = container.BeginLifetimeScope();
_test2(scope);
// example 3
// NOTE THIS!
autofacBuilder.RegisterType<MyService>().As<IMyService>().InstancePerDependency();
var container = autofacBuilder.Build();
void _test1(IComponentContext scope){
var myService = scope.Resolve<IMyService>();
}
void _test2(IComponentContext scope){
// the same scope is used here and in _test1()
// but now service instances will be different even though they are resolved from the same scope
// since registration directs to create new instance each time the service is requested.
_test1(scope);
var myService = scope.Resolve<IMyService>();
}
var scope = container.BeginLifetimeScope();
_test2(scope);
// example 4
autofacBuilder.RegisterType<MyService>().As<IMyService>().SingleInstance();
var container = autofacBuilder.Build();
void _test0(IComponentContext scope){
var myService = scope.Resolve<IMyService>();
}
void _test1(IComponentContext scope){
_test0(scope.BeginLifetimeScope());
var myService = scope.Resolve<IMyService>();
}
void _test2(IComponentContext scope){
// all the scopes used here and in other calls are different now
// but the service instance will be the same in all of them even though it is requested from different scopes
// since registration directs to get the same instance each time the service is requested regardless of the lifetime scope.
_test1(scope.BeginLifetimeScope());
var myService = scope.Resolve<IMyService>();
}
var scope = container.BeginLifetimeScope();
_test2(scope);
How Can I inject IEnumerable<Func<T>> using Simple Injector?
Just to add some context, I'm trying to create all EventHandlers that knows how to handle one specific Event. So here is my Container registration:
container.RegisterCollection(typeof(IHandleDomainEvent<>),
AppDomain.CurrentDomain.GetAssemblies());
And here Are two classes that implement the IHandleEvent<T> interface for the same Event:
public class Reservation : IHandleDomainEvent<OrderConfirmed>{}
public class Order: IHandleDomainEvent<OrderConfirmed>{}
So when I call the Simple Injector:
var handlers = _container.GetAllInstances<Func<IHandleDomainEvent<OrderConfirmed>>>();
I would like to Receive IEnumerable<Func<IHandleDomainEvent<OrderConfirmed>>>
Just to clarify, I know that if I call:
var handlers = _container.GetAllInstances<IHandleDomainEvent<OrderConfirmed>>();
I would get an IEnumerable<IHandleDomainEvent<OrderConfirmed>>.
For interfaces that have only one implementation, registering using:
container.Register(typeof(IHandleDomainEvent<>),
AppDomain.CurrentDomain.GetAssemblies(), Lifestyle.Scoped);
And adding the following ResolveUnregisteredType to the end of the registration:
container.ResolveUnregisteredType += (o, args) => ResolveFuncOfT(o, args, container);
// Function
private static void ResolveFuncOfT(object s, UnregisteredTypeEventArgs e, Container container)
{
var type = e.UnregisteredServiceType;
if (!type.IsGenericType || type.GetGenericTypeDefinition() != typeof(Func<>)) return;
Type serviceType = type.GetGenericArguments().First();
InstanceProducer producer = container.GetRegistration(serviceType, true);
Type funcType = typeof(Func<>).MakeGenericType(serviceType);
var factoryDelegate = Expression.Lambda(funcType, producer.BuildExpression()).Compile();
e.Register(Expression.Constant(factoryDelegate));
}
Will allow calling:
var handler = _container.GetInstance<Func<IHandleDomainEvent<TEvent>>>();
This is the beauty of Simple Injector: You'll never have to resolve an IEnumerable<Func<T>> because any IEnumerable<T> resolved by Simple Injector already functions as a stream.
This means that when you resolve an IEnumerable<T>, none of the elements of the stream will be resolved. They get only resolved when iterating the enumerable, and are resolved one-by-one.
When iterating the stream, elements will be resolved according to their lifestyle. This means that when the elements in the collection are Transient iterating the stream twice will cause the creation of new transient instances.
Example:
// Only resolves the enumerable, not the contained handlers.
// This enumerable itself is a singleton, you can reference it forever.
var collection = container.GetInstances<IEventHandler<OrderConfirmed>>();
// Calls back into the container to get the first element, but nothing more
var first = collection.First();
// Since the stream that Simple Injector returns is a IList<T>, getting the last
// element is an O(1) operation, meaning that only the last element is resolved;
// not the complete collection.
var last = collection.Last();
// Calling .ToArray(), however, will obviously resolve all registrations that are
// part of the collection.
var all = collection.ToArray();
// Iterating a stream will always call back into the container, which ensures
// that the stream adheres to the elements lifestyles. Transients will be
// created on each iteration, while singletons will only be created once.
container.Register<Apple>(Lifestyle.Transient);
container.Register<Banana>(Lifestyle.Singleton);
container.RegisterCollection<IFruit>(typeof(Apple), typeof(Banana));
var fruits = container.GetAllInstances<IFruit>();
Assert.AreNotSame(fruits.First(), fruits.First());
Assert.AreSame(fruits.Last(), fruits.Last());
// Even other collection types such as IReadOnlyCollection<T> behave as streams
var col = container.GetInstance<IReadOnlyCollection<IEventHandler<OrderConfirmed>>();
// This gives you the possibility to get a particular item by its index.
var indexedItem = col[3];
You can find more information on working with collections in Simple Injector here:
Simple Injector Documentation - Using - Collection types
Simple Injector Documentation - Advanced - Auto-Registration
Simple Injector Documentation - Design Decisions -
The API clearly differentiates the registration of collections
Simple Injector Documentation - Collections and lifetime management
I want to create a wrapper class for another type. This works fine until the point where it's necessary that (reference)-equal objects need to have (reference)-equal wrappers.
An example:
public interface ITest<T>
{
T GetInstance(bool createNew);
}
public class Test : ITest<Test>
{
private static Test instance;
public Test GetInstance(bool createNew)
{
if (instance == null || createNew)
{
instance = new Test();
}
return instance;
}
}
public class TestWrapper : ITest<TestWrapper>
{
private readonly Test wrapped;
public TestWrapper(Test wrapped)
{
this.wrapped = wrapped;
}
public TestWrapper GetInstance(bool createNew)
{
return new TestWrapper(wrapped.GetInstance(createNew));
}
}
Test.GetInstance returns always the same instance, as long as the parameter createNew is false.
By contrast TestWrapper.GetInstance returns always a new instance.
Since I want to be able to replace Test with TestWrapper, I search for a solution so that at the end, the wrapper returns a new instance only, if Test returns a new instance. However, the TestWrapper should have no knowledge about the internals of Test.
The test code is
private static void RunTest<T>(ITest<T> cls)
{
var i1 = (ITest<T>)cls.GetInstance(false);
var i2 = (ITest<T>)cls.GetInstance(false);
var i3 = (ITest<T>)cls.GetInstance(true);
var dic = new Dictionary<ITest<T>, bool>();
if (!dic.ContainsKey(i1)) dic.Add(i1, false); else dic[i1] = true;
if (!dic.ContainsKey(i2)) dic.Add(i2, false); else dic[i2] = true;
if (!dic.ContainsKey(i3)) dic.Add(i3, false); else dic[i3] = true;
Console.WriteLine(string.Join(", ", dic.Select(a => a.Value.ToString())));
}
The desired result is
True, False
and that's what you get if one passes new Test() to that method.
If you pass new TestWrapper(new Test()), you'll get
False, False, False
There is a solution based on a simple cache (Dictionary<Test, TestWrapper>) - but with that, I would hold many of the instances in memory without using them any further (and the GC could not collect those instances since there's a reference holding them).
I played around with WeakReferences a bit, but I can't spot a key that I can use to store the WeakReference - thus I have to iterate through the cache list and search for the correct instance which is slow. Besides, I've to implement this solution for every member (with it's very own cache) which seems not to be a great solution...
I hope I have adequately explained my problem ;) So, my questions are:
is there a way to cheat object.ReferenceEquals (that question is unrewarding)
what can I use (as a key for the cache) as an identifier for an object instance (so I can use WeakReference)
is there a better way to achieve a real adapter (where I can replace the adaptee with an adapter without headache)
I've no access to the Test class, and only limited access to the code that uses it (I'm able to pass an arbitrary instance as long it's implements the interface)
No, you can't cheat object.ReferenceEquals(). However, object.ReferenceEquals() is intentionally used very rarely, and usually in cases where things really do need to be reference-equal.
The runtime need it in order to get things right. E.g. if the instance is used as a key in an Dictionary<>
Actually, the runtime typically uses the .GetHashCode() and .Equals() behavior of the individual objects, but it just so happens that if you don't override that behavior in your classes, the base System.Object implementation of those methods relies on the object reference by default.
So if you have the ability to change the code for both the Test class and the TestWrapper class, you can override these equality methods in those classes to ensure that they recognize equivalent objects as equal.
An alternative (and usually better) approach would be to create an IEqualityComparer<> implementation to use in your specific use case. You mentioned keys in a Dictionary<>: you can provide an IEqualityComparer<> instance to the dictionary when it's created to have it test for equality in exactly the way you want.
var dict = new Dictionary<object, object(new TestsAndWrappersAreEqualComparer());
var test = Test.GetInstance(true);
var testWrapper = TestWrapper.GetInstance(true);
dict[test] = test;
Console.WriteLine(dict.ContainsKey(test)); // true
Messenger.Default.Register<OpenWindowMessage>(this, message =>
{
var adventurerWindowVM = SimpleIoc.Default.GetInstance<AdventurerViewModel>();
adventurerWindowVM.Adv = message.Argument;
var adventurerWindow = new AdventurerView()
{
DataContext = adventurerWindowVM
};
adventurerWindow.Show();
});
This code is fairly simple; it just opens a new window and sets the DataContext of the new window. The problem I'm having is that if I execute this twice, the content of the first instance will be overwritten and be set to that of the second since adventurerWindowVM is the DataContext of both windows and it is overwritten each time this code is called. I'm looking for a way to prevent this; I'd like to be able to open multiple windows using this message and have each of them be unique, but thus far I haven't figured out a way to do so. Any advice would be greatly appreciated. I apologize for the vague title; I was unsure of what to name this question. (Also, I know that this isn't a method. What would this block of code be called?)
Update: I'm using MVVM Light and my code is based off of an example somebody provided for me in this answer: https://stackoverflow.com/a/16994523/1667020
Here is some code from my ViewModelLocator.cs
public ViewModelLocator()
{
_main = new MainViewModel();
ServiceLocator.SetLocatorProvider(() => SimpleIoc.Default);
SimpleIoc.Default.Register<GameViewModel>();
SimpleIoc.Default.Register<AdventurerViewModel>();
}
Having given the other answer, I guess I can say the IoC container used here is just SimpleIoC from MvvmLight and to get a new instance of the VM on every GetInstance(...) all you need to do is pass in a unique key every time when trying to resolve an instance of the VM.
So you can switch
var adventurerWindowVM = SimpleIoc.Default.GetInstance<AdventurerViewModel>();
to
var adventurerWindowVM = SimpleIoc.Default.GetInstance<AdventurerViewModel>(System.Guid.NewGuid().ToString());
However as mentioned by the author of MVVMLight Here these VM's will get cached and we need to get rid of them when no longer needed. In your case probably when the Window is closed.
Thus I'd have that entire lambda something like:
Messenger.Default.Register<OpenWindowMessage>(this, message =>
{
var uniqueKey = System.Guid.NewGuid().ToString();
var adventurerWindowVM = SimpleIoc.Default.GetInstance<AdventurerViewModel>(uniqueKey);
adventurerWindowVM.Adv = message.Argument;
var adventurerWindow = new AdventurerView()
{
DataContext = adventurerWindowVM
};
adventurerWindow.Closed += (sender, args) => SimpleIoc.Default.Unregister(uniqueKey);
adventurerWindow.Show();
});
Note:
While this is somewhat longer 3 lines compared to just creating a new VM yourself with (new AdventurerViewModel()) I still favor this because if you use an IoC container to manage LifeTime of your VM's, then have it manage them completely. Don't really like mix-n-match when not needed. Rather keep the IoC Container doing what it's meant to do.
If you need more control over VM injection and Life-time management look at more sophisticated Ioc controllers such as Unity. SimpleIoC was just meant to be a simple get your feet "wet" in IoC kind of container and it does a very good job in that regard.
I think you are trying to use the same instance of your ViewModel with multiple views. So the views will obviously overwrite each others viewmodel contents.
What if you do this;
Messenger.Default.Register<OpenWindowMessage>(this, message =>
{
var adventurerWindowVM = new AdventurerViewModel();
adventurerWindowVM.Adv = message.Argument;
var adventurerWindow = new AdventurerView()
{
DataContext = adventurerWindowVM
};
adventurerWindow.Show();
});
It's a method call, passing in an anonymous method using a lambda expression.
It looks like you are getting your AdventurerViewModel from some sort of IoC container. How is the IoC container configured? In particular, what is the scope of the objects it gives you back? If you have the IoC configured to create objects in singleton scope, for example, then you will always get back a reference to the same object each time. You may need to configure the scope of the object in your IoC container so that it gives you back a fresh copy every time.
How you do that will depend on your IoC container. Without knowing which IoC framework you are using or seeing its configuration, it's impossible to make any further comment.
My advice would be to create an extension method for SimpleIOC. Something like this:
public static T CreateInstance<T>(this SimpleIoc simpleIoc)
{
// TODO implement
}
You already know the method to get the same instance; extended SimpleIoc with a method to create a new instance:
T instance = SimpleIoc.Default.GetInstance<T>();
T createdInstance = SimpleIoc.Defalt.CreateInstance<T>();
If you are not familiar with extension methods, see Extension Methods Demystified
The implementation:
Of type T, get the constructor.
If there is more than one constructor: either throw exception, or decide which constructor to use. Simple method: use the same method that is used in SimpleIoc.GetInstance, with an attribute. More elaborate method: try to find out if you can find registered elements that match one of the constructors. This is not explained here.
Once you've found the constructor that you need, get its parameters.
Ask SimpleIoc for instances of this parameter, or if they should be new also, ask SimpleIoc to create new instances.
CreateInstance
.
public static T CreateInstance<T>(this SimpleIoc ioc)
{
return (T)ioc.CreateInstance(typeof(T));
}
public static object CreateInstance(this SimpleIoc ioc, Type type)
{
ConstructorInfo constructor = ioc.GetConstructor(type);
IEnumerable<object> constructorParameterValues = ioc.GetParameters(constructor);
constructor.Invoke(constructorParameterValues.ToArray());
}
To decide which constructor to use:
private static ConstructorInfo GetConstructor(this SimpleIoc ioc, Type type)
{
ConstructorInfo[] constructors = type.GetConstructors();
ConstructorInfo constructorToUse;
if (constructorInfo.Length > 1)
{
// Decide which constructor to use; not explained here
// use Attribute like SimpleIoc.GetInstance?
// other method: use SimpleIoc.IsRegistered to check which Parameters
// are registered: use ConstructorInfo.GetParameters()
constructorToUse =
}
else
constructorToUse = constructoInfo[0];
return constructorToUse;
}
To get the values of the parameters in the constructor, we need to decide whether we want existing values from Ioc, or create new values:
public static IEnumerable<object> GetParameterValues(this simpleIoc ioc,
ConstructorInfo constructor)
{
IEnumerable<Type> parameterTypes = contructor.GetParameters()
.Select(parameter => parameter.ParameterType);
return ioc.GetInstances(parameterTypes);
}
public static IEnumerable<object> GetInstances(this SimpleIoc ioc,
IEnumerable<Type> types)
{
// TODO: decide if we want an existing instance from ioc,
// or a new one
// use existing instance:
return types.Select(type => ioc.GetInstance(type));
// or create a new instance:
return types.Select(type => ioc.CreateInstance(type));
}
This seems like a lot of code, but most of it is comment and most methods are one liners.