SharePoint is an ASP .NET application, built with many out of the box enterprise collaboration features and a sophisticated customizability model (SharePoint solutions). Unfortunately, it’s an ASP .NET Web Forms application.
Microsoft’s ASP .NET team realized the importance of a clearer and cleaner web development model wherein control is given back to the web developer with ASP .NET MVC. It is a great alternative to ASP .NET Web Forms. Many ASP .NET developers struggled with Web Forms to create web solutions that required more granular control over the outputted HTML and JavaScript (of course there is the advantage of black-boxed web controls and third party products that make a lot of things easy in Web Forms: that’s another thing to consider). One can find lots of thoughts comparing the two on the web.
Although many find ASP .NET Web Forms limiting in many ways, it’s the technology used to build SharePoint as SharePoint predates ASP .NET MVC. Building SharePoint applications using ASP .NET MVC is a different story; you can customize SharePoint by building SharePoint Solutions that use ASP .NET MVC. What I’m talking about here is the system itself: the built-in features and tools. For example, the display, edit, and new forms for lists and items and the master pages in SharePoint are ASPX pages, Web Form pages. In addition, Visual Studio Tools for Office, which includes SDK libraries for SharePoint and project templates for SharePoint solutions, has Web Forms ASPX pages with code behind, and a Visual Web Part project references System.Web by default (System.Web.dll contains the System.Web.Forms namespace).
I think that using Web Forms and the accompanying limitation in a clean architecture is one important factor that makes SharePoint such a hard thing to master. I imagine a much better SharePoint had it been developed using ASP .NET MVC. Technology choices affect architecture which surely affect developer experience in turn. Componentization is part of the process of creating a good architecture, and SharePoint is full of components running here and there (including Windows services), and componentization is only one part of a good architecture and it does not necessarily mean clarity. It also certainly does not mean clarity for the developers who are implementing and building on top of SharePoint.
Diagnosing failure is one primary task of IT specialists and developers. Figuring out why something occurred or behaved the way it did is one vital part of such diagnosis, and wandering a complicated world of componentization and the resulting exponentially complicated possible-solution tree is not a trivial task. SharePoint is not a trivial system and so is diagnosing its issues. I believe I’m not the only one who struggles all the time trying to find out the root cause of a problem.
Components interact as they function. When something fails, the obvious is that the problem could be in one or more of these components. But beyond figuring out whether each of the components is working or not, the interaction modes of those components within contexts (static or dynamic) is also something to consider. For example: suppose a system S composed of components A and B fails. A is working fine, and so might B. But beyond consider that S = A + B, there is an environment E, the host of relevant configuration and other elements, within which A and B might not be able to operate together correctly. This means that the components are fine, but the configuration of the environment causes only their interaction with each other to be faulty. We might also need to check whether the environment has hidden interfering elements, X, Y, and Z that has components in related environments.
As I said before, the search space is huge with SharePoint. I went into the abstract here as this applies to any system, but I’m trying to illustrate the point of why SharePoint is tricky to master, and why is it hard to diagnose it and see through it with clarity and confidence, at least for the non-masters who have been SharePoint-ing since more than a decade.
The thoughts here are provoked because of what happened to me a few days ago while debugging a SharePoint application page.
I will blogged more about that in another post here (404 error on Sharepoint page with ID parameter), but what I faced was an interesting issue with one of my custom SharePoint application pages, wherein I was getting a Not Found (HTTP 404) error in the browser when requesting an application page that surely existed. At first I thought it was some deployment issue as perhaps one of the test deployments remained in an inconsistent state for some failure yet to be diagnosed. Or maybe my code was causing some underlying API to throw an exception not accounted for which was not catchable for some reason by a try-catch. I went on searching for a solution, traversing SharePoint’s complicated possible-solution-tree. The reason that I found surprised me. I will write more about that in a subsequent post.