# IT:AD:Design:Blueprints:Initialization #



<callout type="Navigation" class="small">

* [[../|(UP)]]
{{indexmenu>.#2|nsort tsort}}


</callout>


<panel title="Summary">

Starting an application -- getting it from a state of uselessness in the form of *.dll's sitting on the hard-drive, to a state of in-memory, ready for use, cached for performance, synchronized for scalability, etc. -- takes a lot.

And yet...it's usually left to just a development process of not much more thought than fiddling till the the yellow screen of death is finally gone.

That's not a strategy.


</panel>


## Notes ##


### Quick List of common startup activities ###

* The application actually starts...
    * A first (but false) indication that it has all it's required assemblies.
* Load application settings (settings shared across all server)s.
* Load host settings (application settings specific to the current server in a load balanced or n-tier environment).
* Ensure the connectionstring is correct, and permissions are correctly configured in order to access the database in read only mode.
* Ensure the connectionstring is correct, and permissions are correctly configured in order to access the database in read/write mode.
* Register basic Infrastructure Services.
    * At this point Finally got some logging working.
* Register the rest of the Infrastructure Services.
* Register Domain Services.
    * These generally never fail as they have no inrfastructure dependency.
* Register Application Services.
    * With both Infrastructure and Domain Services, Application Services has everything it needs to startup.
* Potentially Creating the database (using CodeFirst's mechanism).
    * Generally this is a bad bad bad idea unless you are sure that you in a dev environment...but I'll just mention it anyway. 
* Potentially Seeding data into the database in case its empty.
    * Generally this is a bad bad idea...but I'll just mention it anyway. 
* Registering ObjectMapping Maps. You'll need them to map entities across tiers as dto's etc.
* Fetching common reference data.
    * In doing so, proves that mapping seems to be working -- at least for the DTO stuff.
* Caching the common reference data.
    * Cache the reference data in a format as close to the Presentation requirements as possible.
* etc... (i'm sure there's a bit more, but I'll stop here today).


### Use an Dependency Inversion Container System ### 

Study after study after study clearly demonstrate that the reason for projects being unmaintainable is...making monolithic software with tight coupling.

Yet...year after year, I watch enterprise developers start new software projects choosing technologies that promote tight coupling.

Stop!

Using a Dependency Inversion Container system -- such as [[IT/#Unity/]], [[IT/#Ninject/]] or any other is a prerequisite to delivering maintainable value to a client. 

It's so important, so basic a competence, that at this time I will not lead or be involved in any way on a software project that does not use it. 



### Bootstrapping ###

Dependency Inversion solves many problems -- but brings with it challenges -- especially at the initialization stage.





## Resources ##

* [Dependency Injection in Libraries](http://msdn.microsoft.com/en-us/magazine/ee335709.aspx): Initialization used in EntLib 5.0 ... same problem.