How to Build Maintainable and Testable Custom SharePoint

Components

Edin Kapić#SPSSTHLM07

February 14th, 2015

Platinum

Gold

Lunch SharePint

Silver

Web

Beezy

Catalonian SharePoint User Group

sug.cat

Jag frågar mig

är denna öl

SharePint-

kompatibel

@ekapic

www.edinkapic.com

Deployment structure

Solution structure

Source code management

Code structure

Unit testing SharePoint

Maintainable

Testable

Simpler Retraction of one WSP removes shared libraries from BIN/GAC

Only one version path for components

Not granular enough

MySolution.wsp

Functionality can be separately versioned and managed

Retracting one functionality doesn’t break shared libraries

More complex

Limited reusability

MySolution.Specific1.wsp

MySolution.Common.wsp

MySolution.Specific2.wsp

Shared WSP + Feature WSPs

Common SharePoint code can be versioned separately

More control over code reuse and management over multiple solutions

Even more complex

MySolution1.Specific1.wsp

MySolution1.Common.wsp

MySolution1.Specific2.wsp

MyFramework.wsp

MySolution2.Specific1.wsp

MySolution2.Common.wsp

MySolution2.Specific2.wsp

Framework + Shared + Feature WSPs

But

Run away!!!

•

•

“The Truth”

Developer 1

Developer 2

Developer 3Developer 1

Developer 2

Build Server

Corporate

Repository

Unit tests

Depends on abstractions

Separates concerns

Inversion of Control (IoC)

Dependency Injection (DI)

Repository pattern

Service Locator pattern

MVP/MVC

coordinating code

concrete repositories (the ones that hit SharePoint or a database)

CUT

07