Using IoC for Extensibility

MEF is probably a better choice if you know up front there is a good likelihood of consumers wanting to extend your application by injecting their own types.  However, I think there are a few exceptions to this rule.

Firstly, most modern software applications make extensive use of IoC to loosely couple dependencies and allow easy unit testing.  Also, sometimes you don't think it is likely someone will want to swap out a class, but don't want to rule it out either.  Building in MEF support for unlikely cases is a waste of time in my opinion, especially if there are ways to override behaviour using the IoC mechanisms you're already using. In these cases I prefer to allow consumers to override the IoC registered types.

I did a post some time ago on how to prevent IoC configuration chaos (refering to the explosion in size of your app.config if you put all registrations in it). This post discusses using code registrations and a mechanism to automatically run the registration code for each assembly on start-up.

This idea can be extended to allow custom extensions to be added.

By default Unity doesn't allow types to be registered that are not referenced by the application (I think Structure Map doesn't allow this either).

Scenario 1)
A consumer of an application that is already fully completed wants to change some behaviour in that application, and they do not have the source code, just the binaries. The application uses the IoC pattern referenced by the blog post above.
The consumer can create a new application project that references everything the original application and basically wraps around it. The new application includes any new  references required to new assemblies containing classes you want to use in IoC registration.  On start-up the new application simply delegates into the original. Now you can customise the IoC mappings in the App.Config of the new application. This works great for windows services, web services, console applications, and some UI applications. This is the preferable scenario.

Scenario 2)
Another option is to customise the IoC pattern described in the blog post mentioned above. When the initialisation process is looking referenced assemblies in the AppDomain, you can add some IO code to scan for assemblies in a folder.  These new assemblies can be loaded with reflection and added into the AppDomain. Once this initialisation process is complete the App.Config can be applied. This is less desirable because the author of the original application has little control over how customisation are used by the original system. Potentially a security risk.
You could modify the reflection assembly loading mechanism to only allow assemblies with a certain signing key for example to mitigate this security concern.

Type Visualiser version 1.08

Type Visualiser version 1.08

New features and changes:

• Thickness of the dependency line indicates how dependent the subject is on the dependency.
• Added 64 bit and 32 bit release mode executables.
• Allowed combined hide filters (ie combine hide-trivials with hide system types).
• Added support for saving diagrams and reloading them.
• Properly name generic types rather than simply List now will be List.
• Choose type dialog will now remember the last assembly opened.
• Added icons and count for trivial and non-trivial dependencies on the subject.

12 Principles of Agile Software Development

I came across this great presentation on some founding goals for Agile Software Development. Its great to use these principles to base all decisions and processes.
12 principles for Agile Development

View more presentations from Julien Henzelin

Why are we even having this conversation?

I have been in the position of trying to sell the idea of unit testing to management and stakeholders far too many times. In five years time we'll all look back and laugh. It must have been like trying to sell regression testing a few years ago.

Why is quality not a concern? Show me a software company who does not unit test and whose managers are against it and I'll show you a company with unreasonably long release cycles and bad technical debt issues in a fragile code-base. As a seasoned developer and architect unit testing is a given and mandatory for quality assurance reasons, no arguments.

And then there's financial software. The only other kind of complicated software I can imagine where automated testing is more important is life support machines.

There is no such thing as a small simple Financial application, it simply isn't feasible nor possible to manually test all permutations in a large system. Would you trust your money with a bank who isn't thoroughly testing their product to manage your money? I know I wouldn't.

More importantly if you choose not to Unit Test when all your competitors are, your business cannot hope to compete with their agility and quality.
Many studies have been done showing unit testing actually helps software projects meet deadlines and reduce expensive (and sometimes product destroying) bugs in production.
Check out http://www.agitar.com/solutions/why_unit_testing.html and my previous posts on this.

Diagramming tools

http://www.websequencediagrams.com/ A free textual based web tool that generates sequence diagrams based on sentences you type in.

Balsamiq - A mostly UX-centric diagramming tool for drafting User Interface screens.

www.gliffy.com - A simple WYSIWYG style drawing tool that can draw anything. It has some good templates to get you started drawing sequence diagrams.