isolation of external dependencies

I took these pictures of the Eden Prairie Marketcenter Water Tower in Eden Prairie, Minnesota today. The thing is adjacent to my apartment complex, Cascade at Town Center, which is also shown here.

The Wikipedia write up on Eden Prairie namedrops the Cummins-Phipps-Grill House as if it is something to see, but there is really nothing special about it. It is merely the site of the first farm. The only landmark to see that is memorable in the otherwise generic suburban cityscape with a little too much sprawl is the gaudy water tower that has clocks on it. This is a good time to remind you that the timekeeping is an external dependency in a C# application and it should be walled off into the infrastructure project in a Visual Studio solution per the Onion Architecture. The infrastructure project will inherit the core logic project which will have interfaces that the external dependencies (classes) in the infrastructure project implement. The UI project will inherit both the core and the infrastructure projects and use some IoC machinery to hydrate the interfaces with the dependencies. From there the interfaces are passed around to do things with the dependencies. Specifically, they are handed into method signatures (and Controller constructors) consistent with the D in the SOLID Design principles. The water tower example of keeping your timekeeping with your "data" if you will is a good one. The wrong thing to do is to sprinkle DateTime.Now all over the codebase.

A menacing spiked fence surrounds the base of the water tower. The analogy to be had here is that the external dependencies need to be walled off. The sending of emails, web services out to gunk you don't control or for that matter page scrapping of gunk you don't control, that SalesForce account, and flat file reads and writes are all external dependencies.