SharePoint Saturday Stockholm 2015 - Building Maintainable and Testable SharePoint Components

698 views

Published on

SharePoint allows extensibility in many ways for the developers to add functionality by writing custom components such as web parts, timer jobs, event receivers and so on. The unfortunate side effect is that often it explodes into a unmanageable mess. In this session you will learn how to design and write those components with the maintainability in mind. You will see how to properly separate the code that deals with different responsibilities, how to unit test your code, how to add a service layer to your SharePoint customization and how to properly manage the branches and concurrent development.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
698
On SlideShare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Template may not be modified
    Twitter hashtag: #spsbe for all sessions
  • How Beezy branches are done
  • SharePoint Saturday Stockholm 2015 - Building Maintainable and Testable SharePoint Components

    1. 1. How to Build Maintainable and Testable Custom SharePoint Components Edin Kapić #SPSSTHLM07 February 14th, 2015
    2. 2. Platinum Gold Lunch SharePint Silver Web
    3. 3. Beezy Catalonian SharePoint User Group sug.cat Jag frågar mig är denna öl SharePint- kompatibel @ekapic www.edinkapic.com
    4. 4. Deployment structure Solution structure Source code management Code structure Unit testing SharePoint Maintainable Testable
    5. 5. Simpler Retraction of one WSP removes shared libraries from BIN/GAC Only one version path for components Not granular enough MySolution.wsp
    6. 6. Functionality can be separately versioned and managed Retracting one functionality doesn’t break shared libraries More complex Limited reusability
    7. 7. MySolution.Specific1.wsp MySolution.Common.wsp MySolution.Specific2.wsp Shared WSP + Feature WSPs
    8. 8. Common SharePoint code can be versioned separately More control over code reuse and management over multiple solutions Even more complex
    9. 9. MySolution1.Specific1.wsp MySolution1.Common.wsp MySolution1.Specific2.wsp MyFramework.wsp MySolution2.Specific1.wsp MySolution2.Common.wsp MySolution2.Specific2.wsp Framework + Shared + Feature WSPs
    10. 10.  But
    11. 11.  Run away!!!
    12. 12.  •
    13. 13.  • “The Truth” Developer 1 Developer 2 Developer 3 Developer 1 Developer 2 Build Server Corporate Repository
    14. 14. Unit tests
    15. 15. Depends on abstractions Separates concerns Inversion of Control (IoC) Dependency Injection (DI) Repository pattern Service Locator pattern MVP/MVC
    16. 16. coordinating code concrete repositories (the ones that hit SharePoint or a database) CUT
    17. 17. 07

    ×