IoC Frameworks and SharePoint 2010: bringing your SharePoint code under test

here are some notes, on using IoC frameworks with SharePoint 2010, in order to bring code under test.

Prism:

-          Framework to support implementing the MVVM (MVPM) design pattern

-          Flexible UI:

o   Main ‘shell’ window, with regions

o   Modules

§  Each module in a separate project

§  Each module has 1 or more views

§  Each view is assigned to a region

http://compositewpf.codeplex.com/

- NOT for Win Forms

Recommended tools:

- Expression Blend 4

- Win Phone Dev Tools SDK

Dependencies:

- Microsoft .NET Framework 4.0 and Silverlight 4

Problem with use with SharePoint:

-          .NET version 4 ?

-          Prism is really designed for WPF + Silverlight projects

Silverlight inside SharePoint:

-          Prism can be used, where the entire app is a  Silverlight app, that sits inside a SharePoint WebPart

Possible alternative:

- CAB – Composite UI Application Block

- hard to learn ?

- intended for Windows Forms

Alternative:  Microsoft DI / IoC Frameworks:

IoC – Inversion of Control  (where the references with an object, can be decided externally)

DI = Dependency Injection (a special case of IoC, where we can dynamically change the objects that an object depends on)

Unity – an IoC framework: so allows for parts of an application to be mocked out, behind interfaces.

MEF – can be used for IoC.   Also can be used to extend an application after compile time (e.g. this is how Visual Studio 2012 loads its extensions).

Other IoC Frameworks:

There are many IoC frameworks for .NET:

https://code.google.com/p/net-ioc-frameworks/wiki/Charts

Conclusion:

Perhaps Unity is the most suitable, for bringing SharePoint code under test, as it is mainly intended for IoC.

Also, it is Microsoft software, so it should be easier to get approval, if you are working in a restricted SharePoint farm environment.

Example of Unity used within SharePoint:

http://webclientguidance.codeplex.com/wikipage?title=How%20To%3A%20Enable%20Unity%20in%20a%20SharePoint%20Application%20to%20make%20Web%20Parts%20more%20testable

Alternative: re-architect

By carefully architecting the SharePoint application, so that business logic is in a non-SharePoint assembly,

then the code becomes easier to unit test.

This is because the code is not directly depending on externals, like a database or SharePoint.

In theory, if TDD practice is followed, then the architecture will naturally emerge, with code that is not depending on externals.