Timeline for How to deal with dependency when you have separate projects?
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 5, 2015 at 13:53 | vote | accept | Gudradain | ||
| Jun 5, 2015 at 13:53 | comment | added | Gudradain | I like that last solution. The library project is still self contained and testable. From the outside it's perfect but my only grip is 'new FakeDependency()'. FakeDependency might be depending on other dependencies that themselves depend on others. It was kinda my reason to create it via a service locator. All those dependencies use constructor injection of course, because it makes sense there. | |
| Jun 4, 2015 at 18:18 | history | edited | Ewan | CC BY-SA 3.0 | deleted 2792 characters in body |
| Jun 4, 2015 at 18:12 | comment | added | Ewan | but! if you call it GeneralObjectFactoryThatMakesAllMyobjectsWithAnOptionalTestMode I think I would suggest you just expose the interfaces and use DI | |
| Jun 4, 2015 at 18:10 | comment | added | Ewan | If you renamed ServiceLocator and FakeDependency to WidgetFactory and Widget I don't think anyone would raise an eyebrow | |
| Jun 4, 2015 at 18:08 | comment | added | Ewan | It seems like you are squeezing something into a DI/ServiceLocator pattern when you have other options you would be happier with. how about internal void SetTestMode(IFakeDependency dependency) on FakeModel for example? | |
| Jun 4, 2015 at 18:01 | comment | added | Gudradain | It is internal. As other projects have no idea that FakeDependency exists. Other projects have no idea that ServiceLocator exists. The only purpose of ServiceLocator is that if I had written "private FakeDendency Dependency = new FakeDependency()" I would have been unable to write test for FakeModel without also testing FakeDependency. | |
| Jun 4, 2015 at 17:51 | comment | added | Ewan | true, but you still need the ServiceLocator itself to be internal | |
| Jun 4, 2015 at 17:47 | comment | added | Gudradain | internal set? then friend assembly for test project? msdn.microsoft.com/en-us/library/0tke9fxk.aspx | |
| Jun 4, 2015 at 17:44 | comment | added | Ewan | well your set method is the weak point then. if you have it the the class is exposed. if you don't then you dont need a service locator | |
| Jun 4, 2015 at 17:38 | comment | added | Gudradain | By default, the service locator will return the one "true" implementation. When you want to test, you set a "test" implementation. There is nothing else. So, you could replace the the GET code by : return dependency ?? new FakeDependency(); (In fact, the service locator is a wrapper around DI library but the logic is the same). | |
| Jun 4, 2015 at 17:37 | comment | added | Ewan | The only way I can see of not exposing it at all is to init the dependency in the model. You might as well just new it up | |
| Jun 4, 2015 at 17:30 | history | edited | Ewan | CC BY-SA 3.0 | added 2080 characters in body |
| Jun 4, 2015 at 17:17 | comment | added | Ewan | I think you will end up exposing it either way. maybe you could add your ServiceLocator code? | |
| Jun 4, 2015 at 17:13 | comment | added | Gudradain | Ewan, the service locator in the example is a part of the class library project. And no, I don't want to make it easy to change in the sense that you can provide another implementation if you use that class library. If you exclude the tests, there is and should only be one implementation. And all other project using this library shouldn't even bother knowing it. | |
| Jun 4, 2015 at 17:11 | comment | added | Gudradain | @BenAaronson Yup you got it. In fact, FakeDependency should never be used outside the class library project. The Model provides the public interface of the library project and all the other stuffs should stay hidden. | |
| Jun 4, 2015 at 17:05 | history | edited | Ewan | CC BY-SA 3.0 | added 426 characters in body |
| Jun 4, 2015 at 17:01 | comment | added | Ewan | hmm I shall add more code.. | |
| Jun 4, 2015 at 16:57 | comment | added | Ben Aaronson | I think the question is then should FakeDependency be bound in the application composition point in the project referencing this one, or in the project which it lives? From my understanding, OP is saying that the former is the standard way of doing this, but has the issues that it means that now FakeDependency has to be public and known about by other projects. And also that this same binding has to be repeated in lots of projects. | |
| Jun 4, 2015 at 16:36 | history | answered | Ewan | CC BY-SA 3.0 |