IT:AD:Design:Blueprints:Initialization
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.
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 Unity/, 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: Initialization used in EntLib 5.0 … same problem.