0. The only constant in our business …is… Change is inevitable: Before we start (changing requirements) Before we finish (changing budgets / scope) After we’re done (bugs – I mean new features)

Change is good -- Change Requests are not only invetible…but great. They mean You’re incorporating new ideas… …adapting to the market, not some BA ivory tower! (Then again, the first time, that’s all there was if you were creating a market). And frankly, who likes watching your creation and toys get old and crotchety, right?

Don’t sweat it. No matter how much thought you put into an app’s architecture…guess what… … it’s going to look old pretty quickly. …You’ll wish you could tweak and change it. Made it better, faster, cuter, portable…whatever.

It’s easy. You just have to do what you’ve been hearing about in those theoretical classes… Namely, High Cohesion (ie small classes/units that are related to each other) Low Coupling (Break the stuff apart into different classes, different assemblies) And look for patterns that help you keep that broken up…rather than reassembling back together in an total Ball Of Mud.

Learning how to create loosely assembled apps is worth investing in They solve basic problems that we always face Easier to grock/focus Easier to test Less hassle (in the same office, or different continent) Easier to build, change, add add more features

To create these types of apps, you have to learn new patterns. Or more precisely, relearn old (pre MS/VB…) patterns Specifically: DI ServiceLocator And a tool to make it all easy rather than academic: IoC

Intro: Pro: It’s recognisable…as it’s your average mess And this is good code (look it uses interfaces) Cons: Mishmash of services, more memory needed, more dependencies, etc. Conclusion: Tight coupling = Non easy to swap code around, not modular

.NET 2.0 Went crazy with the Provider Pattern…and pushed it everywhere… Pros: We could play with configuration files till we went blue in the face…(hey look ma, I’m working with XML…yeah) Pros: Did offer a means of hot swapping the Instance from one RoleProvider to another… Cons: on the other end…out of the frying pan into the fire…thing Debug/Trace versus Log4Net. Cons: Still have init issues (who goes first) Cons: Can’t test much here Cons: and a TON of work The factory itself The common shared interface The abstract service base to not have to reinvent the wheel for each implementation (some shared logic) The actual instance (s) The config section classes (and those were a pain!) And if you were exposing as a service…TWO more to make the static method exposed as an instance (WCF can’t do static) …ie REALLY SUCKED

Be HONEST. Say up front what you need. Amazingly, if dealing with Instances, you’re no longer bound to anything. The world works this way – on trust/contract. Why shouldn’t your code? Side benefits are multiple…can replace one service with a mock

A service Locator pattern is a bit of a sideways solution… it’s just a dictionary really: interface to Instance.

Loose Coupled Apps

The only constant in IT …is change.

Change is Good = Make Fresh -- with New Ideas = Responsive to new Market Needs = No need to watch your creation get oooold …

Everything gets stale …this year’s Car of the Year… …all to quickly becomes … ….sooo last year’s whatever…

It’s easy (really). The secret is… Apply: High Cohesion Low Coupling Put together in loosely held together design

Advantages Easier to concentrate on parts rather than the whole Easier to test (shims/mocks) Allow development in isolation Easier to add features

Patterns/Tools that help Dependency Injection Pattern Service Locator Pattern Inversion Of Control (IoC)

Comparing ways of developing (not all of them very flexible…) To demonstrate the value of Dependency Injection, and IoC frameworks, and how it helps with creating decoupled applications, let’s do a quick dip into 4 common development patterns Tightly coupled code The Factory Pattern The Inversion of Control (IoC) Pattern The Service Locator Pattern And once we’ve shown the pros and cons of each: How an IoC container can make it even better How Unity or Ninject can be put to use in this regard …

1.The Usual Mess… Child Module instantiates the Resources/Services it needs Pros: Straightforward / Easy Only thinking about own needs. Cons: What’s the initiation sequence? How do they all use the logger? How does the Repo find ConnString Settings? Instantiating nested objects? How do they access services not listed here? Future changes? (Db v. File logging?) Testing? Mocking? Wasting resources? Each child instantiate/duplicating services… Tight Coupling: each module assembly has a dependency on the service implementation and its assembly. …

2.The Provider Pattern Using indirection to decouple from the instance Pros: Often externally configurable (eg: Logging FilePath, in .config). No longer tightly coupled to the Service Instance assembly… Cons: …but now bound to Factory’s instance Still have init. sequence issues Haven’t improved testability much Often much more work: The Factory and its logic… The common Interface… An abstract ServiceBase… The actual Instance(s)… Config section classes. And 2 more if exposed as DataContract! …

3. Dependency Injection Using services passed in as constructor contract arguments. Benefits: All modules share same services. Modules are decoupled from the Service Instance Assembly. (bound by Contract, not Instance). Improved testability: Can mount it in a test rig. Can pass it various alt services. Considerations: Needs as args all services needed to instantiated nested objects If poorly designed, potentially a large constructor arg count …

4. The Service Locator Pattern A common dictionary of instantiated services (by type) A simple class (basically 2 methods) wrapping a dictionary of Services registered by Type. The parent shell instantiates a global ServiceLocator… packs it with the applications services Ii the required order… then passes the whole SL bag to newly instantiated Child objects… Child objects Get only services it needs. Benefits: Services needed by child objects -- even if not needed by module – are findable. Considerations: Everyone takes IServiceLocator dependency Decoupled. Good. But we can do better. …

4b.Service Locator Pattern internals…It’s really just a <IType, Instance> dictionary … I said the Service Locator was simple…

The choices Solving common problems We’ve demonstrated 4 common development patterns: Tightly coupled (The Usual Mess) The Factory Pattern The Dependency Injection Pattern The Service Locator Pattern It’s time to show you a better solution for creating loosely coupled modules: The DI + SL = IoC Pattern …

Dependency Injection Containers Automatically assigning dependencies at creation DI? SL? DI? Magic words? Not a bit: we just did DI/SL/IoC …remember? A simple IoC is just a service that Combines the ServiceLocator pattern + the Builder pattern Pros: No dependency on IServiceLocator Object not responsible for finding its dependencies (ie: IoC) (and therefore decoupled) Dependencies auto injected into the constructor args (hence called DI). Except that instead of a parent creating and injecting the services… …its offloaded to a neutral 3rd party – the DI Container. That’s all that a basic DI Container is! …

Unity Microsoft’s Dependency Injection Container. So what’s Unity? Unity is a fast, lightweight, flexible, configurable, extensible, implementation of the DI Container strategy. Supports registering services, as well as objects by name, as singletons, and various other scenarios. Provides an extended methods for creating objects, fully injected with service and objects dependencies. No object class attributes required*. Supports DI of services and objects into: Constructors Properties decorated with attributes. Method calls decorated with attributes. Supports hierarchical containers. Configurable by code or config files Fast, Lightweight(121Kb), Extensible …

Unity in action Simple! Create a Container Register a Service Resolve a Service Register a Singleton Register and Resolve Named Instances

Unity: Conclusions A great means for creating loosely coupled applications Pros Improves testability. Simplifies management of crosscutting concerns. Increase flexibility by deferring component configuration and DI roles to the Container. Unity supports abstraction of requirements (config or code).

Unity (The End)