Timeline for Handling disposables with dependency injection
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 11, 2018 at 12:29 | comment | added | Flater | You're telling me to do the thing that I'm asking how to do correctly. You're not telling me how to achieve that, just that I should. | |
| Jul 11, 2018 at 12:05 | comment | added | Ewan | I hear what you are saying, both methods are not exactly the same as the current way. My point is that in both cases the resource is disposed of and you have avoided the factory class | |
| Jul 11, 2018 at 11:47 | comment | added | Flater | 2. The issue is that there is no predefined lifetime when the created objects are never garbage collected because they are referenced by a service that is kept alive. The service keeps the top-level object referenced, which keeps its children referenced, and their children, and ... all the way down to the DbContext. | |
| Jul 11, 2018 at 11:47 | comment | added | Flater | 1. I can't dispose something in a method if it was added in the constructor. If I call the methods of the same object, and I have already disposed its child in the first method call, the second method call will encounter issues trying to use an already disposed child object. The continued logic of this is that I can only dispose an object during a method call if I created it during that same method call, and the issue is in creating that item in a method, not the constructor | |
| Jul 11, 2018 at 11:28 | comment | added | Ewan | I'm not sure what your issue is. suggestion 1: refactor so the dispose is called within FooRespository. (dispose will presumably be called per method as in your example) suggestion 2:Dispose will be called at the end of the DI lifetime, set the lifetime to the appropriate scope (dispose is called at a higher level that your example, but is still called) | |
| Jul 11, 2018 at 11:20 | comment | added | Flater | Your linked answer says that "Ninject disposes every Disposable object [..] as soon as the scope object to which the created object is tied is collected by GC" The problem situation (Windows service) is a case where the created object does not get disposed (as the service is kept alive), and stays referenced, thus keeping all of its injected child properties (and their injected shild properties) alive and not disposing/collecting them. | |
| Jul 11, 2018 at 10:23 | comment | added | Ewan | check out this question/answer stackoverflow.com/questions/10234802/… | |
| Jul 11, 2018 at 10:22 | comment | added | Ewan | if in setting up the DI you know that your chosen implementation requires disposal then you can use the life time controls to ensure it is disposed after use, regardless of whether its web or not. you have a 'request context' in terms of 'the request to the DI for an instance of IFooRepository' | |
| Jul 11, 2018 at 10:20 | comment | added | Ewan | exactly. IFooRepository implementations should dispose of their resources internally as required and not require the calling code to call dispose | |
| Jul 11, 2018 at 10:06 | comment | added | Flater | Failing to implement a dispose creates a dependency. It requires the library to only be used in a web context (where there is automatic request scope), since non-request-scoped environment will end up with unexpected behavior. I'm also not sure about your edit, the issue I'm trying to prevent is specifically for windows services which fail to dispose of the object themselves. The consumer (API/windows service) shouldn't be aware of the underlying technologies used, and by extension shouldn't be the one who chooses to dispose or not if not disposing causes unwanted behavior and bugs. | |
| Jul 11, 2018 at 10:02 | history | answered | Ewan | CC BY-SA 4.0 |