5

like this https://github.com/seesharper/LightInject/blob/master/LightInject/LightInject.cs

It's hard to reading, is there any deep meaning?

Steven
  • 166,672
  • 24
  • 332
  • 435
Rwing
  • 490
  • 4
  • 19
  • It's completely up to the author. Though it is worth wondering why he has 5k lines of codes in one file – Jonesopolis Feb 28 '14 at 05:08
  • Hey guys, why closed? did you see the author's answer? it's a meaningful question! – Rwing Apr 10 '14 at 08:56
  • @Rwing unfortunately this is how many Stackoverflow members treat users, especially new users. I always do my best to get questions reopened because they have value. – Chris Marisic Apr 13 '15 at 16:22

2 Answers2

15

Being the author of LightInject, I feel I should comment on this :)

Say that you are a library developer and want to be able to utilize an IoC framework internally without taking a dependency on a third party assembly. By using the source version of LightInject, this can be done quite easily and you can still ship your library as a single assembly.

Many framework developers choose not to use an IoC framework just because they don't want that extra dependency.

The alternative to this would be to use tools like ILMerge that is capable of merging two or more assemblies into a single assembly.

This is a far more advanced option and would also require an extra build step that performs the merging.

Note that LightInject comes in two flavors, the source version where all the types are internal and the binary version that acts just like any other third party dependency.

Taking on a dependency might not seem so bad at first, but if you are a framework developer, you could easily run into issues if the consumer of your framework uses another version of the same dependency

Best regards

Bernhard Richter

seesharper
  • 3,249
  • 1
  • 19
  • 23
  • Thank you for the clarification and to the OP for being brave enough to post an odd but reasonable question. I have to admit when I first cruised through the LightInject docs I bumped into the explanation for internal scope only source code usage and thought "why no conventional DLL with a public api?". This reply helps clarify the dual mode usage/deployment scenario. Makes perfect sense now, I will be using the LightInject library packaged as a standard DLL. – camelCase May 03 '14 at 12:01
  • I want to use LightInject because it's the fastest. Why doesn't LightInject support xml configuration? Seems like specifying the maps in code defeats the purpose of DI? (DI newbie here). Thanks. – toddmo Mar 12 '15 at 03:07
  • @toddmo you **never** *need* container services registration via XML. I would also go as far as to say it is literally an antipattern. If you seriously need that level of variance MEF's component architecture that can support addins during runtime is a much better starting point. – Chris Marisic Apr 13 '15 at 16:20
  • @ChrisMarisic, I'm not arguing, I just don't know. So add-ins would be configured in the xml? – toddmo Apr 13 '15 at 16:23
  • @toddmo I would never use config files by choice for any reason other than appsettings/connectionstrings. Outside of that there's alot of forced usage of config files by .NET sadly. – Chris Marisic Apr 13 '15 at 16:34
5

It makes integration as source in another project easier: simply add one file to your project and forget about it. This is a supported installation scenario according to the official website of LightInject, there's even a NuGet package for it.

If you want to read it, I'd strongly suggest opening it in Visual Studio and using the code navigation features to find what you want, e.g. VS 2013's Solution Explorer can display the classes inside of a file as children of that file.

Solal Pirelli
  • 1,199
  • 9
  • 21