This project is read-only.

Whay is this project about?

It’s a fact: even if SharePoint has become one of the major platforms for development of business solutions, those solutions are often considered to be different – they are considered to be developed differently, that they don’t follow commonly accepted architecture practices, and that automated testing is not possible. Solution architecture directly impacts all of the following steps of the ALM cycle: development, testing, quality assurance and deployment.

This is the reason I have decided to start a project, which will try to show that it does not have to be that way, at all. The main goal of this project is to show how to apply known and established architecture patterns into architecture of SharePoint solutions, how to increase code readability and maintainability, and how to deal with the code testing. This CodePlex project is an accompanying solution to the series of the articles on my blog, which will be dealing with the SharePoint architecture principles, practices and issues.

Simplfied SharePoint Architecture

The next expected question would be – why would anyone write such a series of articles, when there is a great SharePoint Guidance document (SPG) from Microsoft’s Patterns & Practices team. To make one thing straight: series of articles is on my blog is not meant to be an alternative to SPG. SPG is still the ultimate resource for all SharePoint Architects and senior developers, which should, by my opinion, be read in the regular intervals (just that we do not forget the things). I will, from time to time, publish here some different approaches to the same topics covered by SPG (like configuration and service location), and, whenever I do, I will always state my reasons why did I take that specific approach. Basically, SPG is in some aspects way too much SharePoint, and it tends in these topics to keep considering SharePoint solutions as being different. That way, problem can occur when we create mixed solutions – SharePoint and general .NET or other technologies – SPG approach is in these cases usually not appropriate. But in most of the cases: SPG is a way to go.

All the articles wich I publish on my blog will be accompanied with the real, living code, published here. The test solution will be the about the conference organization: if you have ever been to a SharePoint conference, or any other development conference for that matter, you know that there is a lot of stuff to be done – from the speakers’ perspective (speaker bios, session abstracts, session schedule…), but mostly from the visitors’ perspective (applying for the conference participation, registering for a single session, rating a session…). Even if this project is mainly intended to demonstrate SharePoint Architecture principles and techniques, I still want to have a functioning solution on the end of the day. The complete solution description can be read here.



Articles Published until now:

But it’s SharePoint (08/18/2011) 
A Post which describes the motivation behind this project

SharePoint Architecture – What are we talking about here? (09/03/2011) 
Some general thoughts about architecture of SharePoint Solutions

The Conference Organization Solution (09/10/2011) 
General description of the solution which will be developed in course of this series of articles

Architecting Sharedove Conference Organization Solution: Data First (10/03/2011, 10/07/2011)
Developing data model and business entities for Sharedove Conference Organization Solution


Last edited Oct 7, 2011 at 5:18 PM by adisjugo, version 10