Merge branch '1.0.0' of https://github.com/BindToConfig/BindToConfig …

…into 1.0.0

README.md

@@ -1,17 +1,19 @@
 # BindToConfig .Net Core
+***BindToConfig*** is a simple and lightweight alternative to ***.NET Core Options***. 
+Focused on simplicity and good practices. Which means it doesn't require any additional interface on classes. 
+It promotes creating many small, clean, immutable classes that are a representation of application's configuration and it's lifetime scope and binding to the configuration are set in composition root, not directly by dependent classes. 
 
-The goal of ***BindToConfig*** is to provide for .net core applications an easy way of handling classes representing *Configuration / Settings*. ***BindToConfig*** fills the gap between .net core's *Configuration* and *DI*. 
-It take cares of objects creating, binding and registering in .net core *DI*.
-To promote creating many small classes which source of values is application configuration. 
+***BindToConfig*** fills the gap between .NET Core's Configuration and DI, by taking care of mapping and binding objects to the configuration, validating and registering in .NET Core DI. 
+With just a single method call it provides .NET Core applications with an easy way of adding classes representing parts of Configuration. 
 
-It's built with the simplicity and promotion of best practices in mind. 
+Built with the simplicity and promotion of best practices in mind
 * Interface Segregation Principle - no additional  interface is required
 * Immutability
 * Fail-fast
+* Composition root 
 * Base what is need: ``services.BindToConfig<ConfigClass>(..)``
 
-It's small, lightweight, free and open-source. 
-It is an alternative to .net Options library that has serious design pitfalls that force violation of good practices.
+*small, lightweight, free and open-source.*
 
 ## Example
 Binding configuration Classes to app's configuration is very simple.  
@@ -21,8 +23,13 @@ Startup.cs :
 public void ConfigureServices(IServiceCollection services)
 {
   services.AddMvc();
-  services.BindToConfig<SampleConfig1>(Configuration, "ConfigValues1");
-  services.BindToConfig<SampleConfig2>(
+  // adds SampleConfig1 as Singleton
+  services.AddFromConfig<SampleConfig1>(Configuration, "SectionKey1");
+  // adds Sample Config2 as Scoped, 
+  // new scopes return updated Config2 object when configuration changes
+  // use it only when You really use live-updates of configuration
+  services.AddBoundToConfig<SampleConfig2>(Configuration, "SectionKey2");
+  services.AddBoundToConfig<SampleConfig3>(
       Configuration,
       "NonExisting",
       BindOptions.DontThrowIfSectionIsMissingOrEmpty);
@@ -35,16 +42,17 @@ And then You can
 public class ValuesController : ControllerBase
 {
 ...
-public ValuesController(SampleConfig1 config1, SampleConfig2 config2)
+public ValuesController(SampleConfig1 config1, SampleConfig2 config2, SampleConfig3 config3)
 {
   _config1 = config1;
   _config2 = config2;
+  _config3 = config3;  
 }
 ```
 
 ## Key features
 - Pure configuration classes without any additional interface like IOptions or IOptionsSnapshot
-- Automatic registration in .net core DI
+- Automatic registration in .NET Core DI
 - Automatic binding to Your configuration
   - detects and updates object automatically when configuration will be changed - if reloadOnChange is set to true for file configurations. 
   Each new request will use config with updated values. BindToConfig uses Scoped lifetime for registration.