Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>For myself one of the main reasons to use an IoC (and make use of external configuration) is around the two areas of:</p> <ul> <li>Testing</li> <li>Production maintenance</li> </ul> <p><strong>Testing</strong></p> <p>If you split your testing into 3 scenarios (which is fairly normal in large scale development):</p> <ol> <li>Unit testing</li> <li>Integration testing</li> <li>Black box testing</li> </ol> <p>What you will want to do is for the last two test scenarios (Integration &amp; Black box), is not recompile any part of the application.</p> <p>If any of your test scenarios require you to change the configuration (ie: use another component to mimic a banking integration, or do a performance load), this can be easily handled (this does come under the benefits of configuring the DI side of an IoC though.</p> <p>Additionally if your app is used either at multiple sites (with different server and component configuration) or has a changing configuration on the live environment you can use the later stages of testing to verify that the app will handle those changes.</p> <p><strong>Production</strong></p> <p>As a developer you don't (and should not) have control of the production environment (in particular when your app is being distributed to multiple customers or seperate sites), this to me is the real benefit of using both an IoC and external configuration, as it is up to the infrastructure/production support to tweak and adjust the live environment without having to go back to developers and through test (higher cost when all they want to do is move a component).</p> <p><strong>Summary</strong></p> <p>The main benefits that external configuration of an IoC come from giving others (non-developers) the power to configure your application, in my experience this is only useful under a limited set of circumstances:</p> <ul> <li>Application is distributed to multiple sites/clients where environments will differ.</li> <li>Limited development control/input over the production environment and setup.</li> <li>Testing scenarios.</li> </ul> <p>In practice I've found that even when developing something that you do have control over the environment it will be run on, over time it is better to give someone else the capabilities to change the configuration:</p> <ul> <li>When developing you don't know when it will change (the app is so useful your company sells it to someone else).</li> <li>I don't want to be stuck with changing the code every time a slight change is requested that could have been handled by setting up and using a good configuration model. </li> </ul> <p><em>Note: Application refers to the complete solution (not just the executable), so all files required for the application to run</em>.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload