问题
I'm trying to retro-fit (bad idea I know, but better late than never) IOC and DI into an existing solution.
The code base is made of up about 30 projects, each which have classes in them which have little or no visibility to the outside world. Being relatively new to the IOC thing I'm trying to use best practise when reworking the code, and it seems best not to pass the IOC container around or make it static, hence I'm trying to do everything via constructor injection.
However, and here comes my question, I am having to make an awful lot of the classes public across projects (i.e. physical .csproj files). I'm having to do this because my 'configuration module' (i'm using Ninject, but this is an IOC agnostic question) needs to know about everything in any class in any project in order to be able to resolve the dependencies.
Have I missed something significant? Are all my classes supposed to be public if they are based on an interface? Can I somehow create an IOC container for each of my csproj boundaries and have that do the injection for me?
Ta
回答1:
Could you not write a configuration module inside each project, and only make that public? Then configure ninject with all of the modules instead of a single one...
回答2:
I believe you're on the right track. In general any IoC Container is going to need to be aware of (a) the interface and (b) the implementation so it can wire everything up. You generally do the "wiring" in higher-level modules (your configuration module project in this case); the lower-level modules don't need to know about all possible implementations of the interfaces. In order to make this happen (and to facilitate testability) the implementations need to be public.
If you really wanted to you could use InternalsVisibleTo, but I wouldn't. If you were not using IoC, you'd need to make these classes public anyway.
You could also look into MEF; apparently it allows the implementations to be private or internal.
来源：https://stackoverflow.com/questions/3579198/ioc-across-visual-studio-projects