-
Notifications
You must be signed in to change notification settings - Fork 0
/
CHANGES.txt
136 lines (95 loc) · 4 KB
/
CHANGES.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
----------------
Version 0.8.1
----------------
Minor performance improvements.
----------------
Version 0.8
----------------
API change for custom Lifestyles.
Before:
using IfInjector.IfBinding.IfLifestyle;
To
using IfInjector.Bindings.Lifestyle
----------------
Version 0.7
----------------
This is a major change. The most important change is that for 'explicit' bindings (EG Bind(..)) the system will now throw an exception once you have called Resolve(). This move to immutability solved a number of edge nasty edge cases.
Also at a functional level, for property injection bindings have been split for instance binding; this allows for explicit configuration of each.
At an API level, the syntax for explicit bindings has changed from:
injector.Bind<BindType, ConcreteType>()
.AddPropertyInjector(...)
.AddPropertyInjector(...)
.AsSingleton();
To
injector.Register(Binding.For<BindType>().To<ConcreteType>()
.InjectMember(...)
.InjectMember(...)
.AsSingleton());
Finally, in terms of new features, V0.7 adds custom lifecycles.
-------
To create / use a custom lifestyle
var myCustomLifestyle = Lifestyle.CreateCustom(instanceCreator => {
ThreadLocal<object> instance = new ThreadLocal<object>(instanceCreator);
return () => {
return instance.Value;
}
});
injector.Register(Binding.For<BindType>().To<ConcreteType>()
.InjectMember(...)
.InjectMember(...)
.SetLifestyle(myCustomLifestyle));
----------------
Version 0.6.1/0.6.2
----------------
It turns out, for whatever reason, nuget was packing my debug .dll rather than my release .dll. Packaging the correct DLL resolved the issue.
----------------
Version 0.6
----------------
DEPRECATED
OLD WAY:
Injector injector = Injector.NewInstance();
NEW WAY:
Injector injector = new Injector();
CHANGES
Major:
- Providers:
- Decide on use of injector.Resolve<>() for provider
- You may now do the following to inject a copy of the injector into your class
class MyClass {
[Inject]
private Injector injector;
}
- The internal packaging structure has been completely refactored to break the . This is to ready the code
Minor:
- Clean up of units
Open Issues
- 30-40% performance degredation as compared with V0.5.1
----------------
Version 0.5.1
----------------
Major
- Property injection with factories were broken
- Changed dependency chain clearing logic to maintain type=>Set(IResolvers) map
- This ensures that clearing a type only modifies types that depend on the given type
- The practical reason for this is if you have 1000+ objects I was looping over all of them each time you changed a binding
- With the change, I only clear the the dependencies and which removes them from the type=>Set(IResolver) list
- Thus, if you have 5+ dependencies, I only tell each of them to clear themselves once
- Fixed edge condition where 2 concurrent threads cause double initialization of singleton
- Refactored unit tests and increased coverage of factores to help avoid repeat.
Minor
- Code Hygene
----------------
Version 0.5
----------------
Added support for WF7.5. For 'factory' based construction there are some performance degredations - most of which are neglibible if you only use 'property injection'. For 'field' injection, the changes forced the use of reflection.
To give a very concrete example, this is the only thing that requires heavy reflections:
class MyType {}
class MyOtherType {
[IfInject] // Could also be .AddPropertyInjector() style binding
public MyType MyType; // public vs private does not matter here, just that it is a 'field' rather than a property
[IfInject]
public MyType MyTypeProp { get; private set; } // This will cause NO issues
}
injector.Bind<MyOtherType>().SetFactory(() => return new MyOtherType());
// NOTE: the following will not suffer, as I am able to leverage a more performant LINQ expression for constructors.
injector.Bind<MyOtherType>(); // NOTE: no factory