And I remember it every single time I need to work with the SPContext object. Remember: doing ridiculous things in the obscure environment? Exactly.<\/p>\n
So, let’s talk about the SPContext.<\/p>\n
<\/p>\n
It is actually nothing else but a derivate of a well known HttpContext. Microsoft words: “Represents the context of an HTTP request in Microsoft SharePoint Foundation<\/a>“. For the most of the times, you just use it in the SharePoint front end, to know where exactly you are \u2013 to retrieve the current SPSite, SPWeb, SPList, SPListItem… whatsoever object, which is currently of interest to you.<\/p>\n Well, there we see already a few tricks and drawbacks. SharePoint front end? Yes, SharePoint front end. We know our SPContext in our web parts and application pages.<\/p>\n But, we don’t want to talk to our SharePoint Data from our web parts. We just don’t want. It’s not a nice thing to do, and we don’t do that. Our data access layer needs a SPContext, not our front end.<\/p>\n Since it takes some time to initialize the data we have in SPContext \u2013 waking up a SPWeb could take some seconds \u2013 it would be nice thing if we could pass our SPContext from the front end, to the SharePoint data access layer. We can, nothing stops us to do that \u2013 we will see in one of the next articles of this architecture series how to do that \u2013 but that is actually not an issue. That is straight forward.<\/p>\n You remember the last article in the Sharedove SharePoint architecture series, the one which where we described creating a Windows 8 Metro Client that consumes SharePoint data<\/a>. Well, we don’t have a SPContext there. As we have said, we have it only in the SharePoint front end components.<\/p>\n If we look at this schema, we clearly see two paths from which the SharePoint data are accessed: one is through the SharePoint UI (front end) layer \u2013 this is where we have SPContext, and the other one is through the Service Layer, which is used by all other front ends for our data. We don’t have our context there. The orange marked components and arrows.<\/p>\n Well, we want to use the same SharePoint data access layer for both cases \u2013 it would be a waste of time to write a data logic twice. This means, we need to create our own context objects \u2013 SPSite and SPWeb.<\/p>\n But, there is another issue here, which need to discussed, even before we created a SPWeb: how to get rid of it. Yes, we need to dispose SPWeb and SPSite objects manually. .NET will not do it for us. But \u2013 not if we use the SPWeb which we have received from the SharePoint UI (web parts). If we dispose that one, we have just put our SharePoint to sleep. So we need to differentiate: if we come from SharePoint UI \u2013 no disposing. If we come from any other place \u2013 we must dispose it. This does not make the things easy, does it.<\/p>\n Let’s look at our SharePoint Data Access Layer project (the code can be downloaded from the Sharedove Architecture Project CodePlex site<\/a>). We will create a ContextHelper class, which will help us in handling all the tasks related to the SPContext issues.<\/p>\n In each public method in out data layer class, we will first create a ContextHelper class, and pass a context object to it \u2013 ContextHelper constructor requires some context object to be passed. The context object will be of a type “object”, but we will actually expect a SPContext object (if coming from the SharePoint UI), or a string object (if we are creating the object manually).<\/p>\n If we pass a string, we will establish a connection that it will be in format {site};{web}, means, site and web separated by a semicolon. That will be enough info for us to create a SPSite and SPWeb<\/p>\n In the ContextHelper constructor<\/strong> itself, we will determine which type of object did we pass. If it was a SPContext, we will just assign SPSite and SPWeb objects from the context to the member variables, which are then exposed as public properties from the ContextHelper<\/strong> objects.<\/p>\n ContextTypes<\/strong> enumeration is used to remember what context did we use.<\/p>\n But, if we have passed the string as a context object, we need to create our SPSite and SPWeb ourselves:<\/p>\n We notice here, that we are creating SPSite and SPWeb without using the “using<\/span>” block, which would do the SPSite\/SPweb disposal for us. The reason is very simple \u2013 we need our SPSite and SPWeb, we must use it in our data access layer methods. And get rid of it afterwards. This means that we need a DisposeContext<\/strong> method in our ContextHelper<\/strong> class, which will be called at the end of the each Data Access Layer method, to dispose SPSite and SPWeb, if they need to be disposed:<\/p>\n And then \u2013 what if an exception has been thrown between SPSite\/SPWeb creation through the ContextHelper<\/strong> class, and SPSIte\/SPWeb disposal through the DisposeContext<\/strong> method? Does this mean that these object would remain in memory, consuming it without any need? This is why we will create a ContextHelper destructor<\/strong> method, which will be created always when our ContextHelper class is disposed, where we ensure that out SPSite and SPWeb objects are non existing when at the moment.<\/p>\n The legitimate question would be \u2013 why do we need to call the DisposeContext method manually then, from our methods, when the SPSite\/SPWeb will be disposed anyway through the destructor \u2013 well, because it is a nice thing to do. It makes us aware of what is actually going on there.<\/p>\n Last, but not the least \u2013 we started speaking about SPContext, and ended up creating SPSite and SPWeb. Well, these are two most common objects you actually need from the SPContext, which cover 95% of the needs, but if you really need a whole SPContext object created, just remember that it is a derivate of HttpContext. And since we already have a SPWeb object created above, it is not a difficult task to derive the SPContext:<\/p>\n Well, this makes the whole story working, both for web parts, Windows 8 Metro clients. Another myth about SharePoint being “different<\/em>“, and “needs to access the data from the UI<\/em>” broken. There is a data access layer, implemented in a clean way, which enables us to access the SharePoint data from wherever we come, exactly as we have wanted it.<\/p>\n The whole source code, as always, at http:\/\/sharedove.codeplex.com<\/a><\/p>\nThe Problem<\/h3>\n
![\"SPContext](\"https:\/\/blog.sharedove.com\/adisjugo\/wp-content\/uploads\/2011\/11\/SPContext-games_thumb.png\" "\\"SPContext")
<\/a><\/p>\nThe solution<\/h3>\n
\n\/\/\/ <summary>\n \/\/\/ Initialize the Context Helper class - check the type of the passed context, and, if necessary, instantiate SPWeb\n \/\/\/ <\/summary>\n \/\/\/ <param name="context">Context object which we have received<\/param>\n public ContextHelper(object context)\n {\n m_ContextType = ContextTypes.Unknown;\n\n if (context is SPWeb)\n {\n m_ContextType = ContextTypes.Spcontext;\n m_Web = context as SPWeb;\n m_Site = m_Web.Site;\n }\n else if (context is string)\n {\n m_ContextType = ContextTypes.Initialize;\n CreateContext(context as string);\n }\n }\n<\/pre>\n\n\/\/\/ <summary>\n \/\/\/ Initialize the Context Helper class - check the type of the passed context, and, if necessary, instantiate SPWeb\n \/\/\/ <\/summary>\n \/\/\/ <param name="context">Context object which we have received<\/param>\n public ContextHelper(object context)\n {\n m_ContextType = ContextTypes.Unknown;\n\n if (context is SPWeb)\n {\n m_ContextType = ContextTypes.Spcontext;\n m_Web = context as SPWeb;\n m_Site = m_Web.Site;\n }\n else if (context is string)\n {\n m_ContextType = ContextTypes.Initialize;\n CreateContext(context as string);\n }\n }\n<\/pre>\n\n\/\/\/ <summary>\n \/\/\/ Dispose context\n \/\/\/ <\/summary>\n internal void DisposeContext()\n {\n \/\/\n \/\/Dispose the context if it was initialized manually (not passed from the Front End)\n if (m_ContextType == ContextTypes.Initialize)\n {\n try\n {\n \/\/\n \/\/dispose web and site\n if (m_Web != null)\n m_Web.Dispose();\n\n if (m_Site != null)\n m_Site.Dispose();\n\n\n }\n catch (Exception ex)\n {\n throw new ApplicationException("Could not dispose the context", ex);\n }\n\n }\n }\n<\/pre>\n\n\/\/\/ <summary>\n \/\/\/ When disposing ContextHelper, look in the destructor if the SPWeb is disposed - if it should be disposed at all. \n \/\/\/ Dispose it if it isn't \n \/\/\/ <\/summary>\n ~ContextHelper()\n {\n DisposeContext();\n }\n<\/pre>\n\n\/\/\/ <summary>\n \/\/\/ Sets the current SPContext, based on the SPWeb value, if not present. Since the SPContext is based on the HttpContext, \n \/\/\/ it is current Http Context that we will actually be setting\n \/\/\/ <\/summary>\n private void setCurrentSpContext()\n {\n \/\/\n \/\/ Ensure HttpContext.Current\n if (HttpContext.Current == null)\n {\n HttpRequest request = new HttpRequest("", m_Web.Url, "");\n HttpContext.Current = new HttpContext(request, new HttpResponse(TextWriter.Null));\n }\n\n \/\/\n \/\/ SPContext is based on SPControl.GetContextWeb()\n if (HttpContext.Current.Items["HttpHandlerSPWeb"] == null)\n {\n HttpContext.Current.Items["HttpHandlerSPWeb"] = m_Web;\n }\n }\n<\/pre>\n