Timeline for Using generics for dependency resolution constraints
Current License: CC BY-SA 3.0
27 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
May 4, 2018 at 14:45 | vote | accept | Mykhailo Kilianovskyi | ||
May 3, 2018 at 14:07 | answer | added | Flater | timeline score: 0 | |
May 3, 2018 at 12:54 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
Apr 3, 2018 at 12:08 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
Mar 4, 2018 at 11:52 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
Feb 2, 2018 at 20:53 | comment | added | Laiv | Easy answer. No, it's not good idea. That's not what generics were made for. You won't solve a design flaw with another design flaw. | |
Feb 2, 2018 at 11:15 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
Jan 3, 2018 at 11:13 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
Dec 4, 2017 at 11:16 | comment | added | kayess |
Not sure I have understood your question right, but if so what I would do is: register your use-cases in composition root with Ninject like Kernel.Bind<IIndexer<Activity>>().To<ActivityIndexer>() and so on, or you can write a Func<Type, IIndexer> provider where you could filter out your consumer classes and return (IIndexer) Kernel.Get(yourType) .
|
|
Dec 4, 2017 at 10:44 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
Nov 4, 2017 at 9:56 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
Oct 5, 2017 at 10:49 | comment | added | T. Sar | That's the issue of DI frameworks. They try make something that is already easy, albeit difficult to grasp, easier to use. Most often than not they limit you more than help, however. DI is one of the few things that you're better of doing manually instead of relying on a third party framework. The concept isn't rocket science, it just needs some thinking beforehand. | |
Oct 5, 2017 at 8:58 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
Sep 5, 2017 at 9:14 | comment | added | David Arno | No, they really aren't. If you use a framework, you are coupled to it. I can understand your desire to only lightly couple to it, but then you run into problems like this. Perhaps another option for you would be to hide the container behind an abstraction layer. That way, if you change your mind on which framework to use in future, then you need only change the functionality of that layer; not of your whole app. | |
Sep 5, 2017 at 9:02 | comment | added | Mykhailo Kilianovskyi | @DavidArno coupling with framework and harnessing it are different things, I think) | |
Sep 5, 2017 at 8:58 | comment | added | David Arno | Then don't use a framework; use pure DI and/or code your own resolver and factories. | |
Sep 5, 2017 at 8:57 | comment | added | Mykhailo Kilianovskyi | @DavidArno I feel uncomfortable with these, cause it makes your code dependent on Ninject) ( I observed few times of switching DI framework at project ) | |
Sep 5, 2017 at 8:53 | comment | added | David Arno | You tell it how to choose a specific implementation by using Contextual bindings. | |
Sep 5, 2017 at 8:52 | comment | added | Mykhailo Kilianovskyi | @Euphoric This approach provides tight coupling. I could change my indexer from one search lib to another | |
Sep 5, 2017 at 8:50 | comment | added | Mykhailo Kilianovskyi | @DavidArno , but how it could know which implementation I want at concrete moment? | |
Sep 5, 2017 at 8:36 | comment | added | David Arno |
You shouldn't need to use generics to differentiate them. The resolver is just a glorified factory: for a given rule, it will return a specific concrete class that implements IIndexer .
|
|
Sep 5, 2017 at 8:30 | answer | added | Neil | timeline score: 0 | |
Sep 5, 2017 at 8:23 | comment | added | Caleth |
or avoid void DoSomething() black holes of type erased side-effect
|
|
Sep 5, 2017 at 8:02 | comment | added | Ewan | or use named dependencies to specify which IIndexer is needed | |
Sep 5, 2017 at 7:43 | comment | added | Euphoric | Why not just use concrete indexer class as dependency? DI doesn't require the dependency to be an interface. | |
Sep 5, 2017 at 7:33 | review | First posts | |||
Sep 5, 2017 at 8:25 | |||||
Sep 5, 2017 at 7:32 | history | asked | Mykhailo Kilianovskyi | CC BY-SA 3.0 |