Join Robert Bogue for an in-depth discussion in this video Developing in SharePoint, part of Developing SharePoint Full Trust Solutions for SharePoint 2013.
- Let's take a look at what it means to develop on SharePoint. Developing on SharePoint is different than developing from scratch. There's a whole bunch of things you don't have to do. There's all kinds of structure that's already there for you. And ultimately what that means for you is it's going to be faster to create your complete solutions. There's a whole bunch of stuff you just don't have to worry about. To get us started, let's take a look at this analogy. And if we think about the Statue of Liberty, most of us think about the Statue of Liberty as the gift from France that Eiffel worked on the infrastructure for and we think about just that sculpture.
But if we take a different look at it, we'll see that the Statue of Liberty sits on top of a pedestal. That pedestal was created from money raised from school children, nickels and dimes from all over the United States. And it represents not quite half of the Statue of Liberty's overall height. The pedestal in turn sits on top of a wider base. That base is star shaped and it provides a foundation for even the pedestal. If we think about this from the point of view of developing in SharePoint, it's a good analogy because the base is .NET.
It's very broad, has all sorts of different things, but it's also very shallow. There's not a lot of functionality that you can just leverage in .NET. It's more of a baseline set of under the covers things. The pedestal in the Statue of Liberty is SharePoint. The pedestal is a set of narrower but taller functionality. And it might include things like document management or list management, data management, security. All those sorts of things that SharePoint provides for you.
And so the Statue of Liberty itself, the actual sculpture, is shorter but it gets its total height and its majesty based not just on the sculpture itself but everything that's underneath it. So the .NET and the Sharepoint get lost and all people see is the Custom Development, the sculpture that was created. So let's look at this in more detail. What does it mean to compare .NET development to SharePoint development? Well first, we've got data storage.
And in .NET if you want to store in a database, you've got to get all that worked out. If you want to do presentation, if you want to control the way the page looks, mostly you've got to start that from scratch too. There maybe frameworks like MVC and Razor. But you've still got to figure out what are my menus look like and are they on the top or the left, where do they go? Next is security. You think about how are users going to authenticate. How are you going to manage permissions and their authorization to do things.
After that, you might think about clustering. If you've got a requirement for large scalability or perhaps you have a uptime requirement, you need three nines or four nines or five nines. You've got to figure out how to cluster so multiple servers can be involved. Then there's the APIs that you have to call. You've got a narrower set of APIs inside a .NET. And a much broader, richer set of things that are happening in SharePoint. And that might even include office integration. In .NET, if you need to be able to export to Excel or integrate with Word, you've got to build that yourself.
Lastly when we're building, we've got these features that are unique to whatever it is we're doing. Those features, we're going to have to write whether we're in just .NET or we're in SharePoint. Ultimately what this means is in .Net, there's a lot of custom development. Everything in this stack, we've got to develop more or less from scratch. On SharePoint, everything from data storage to office integration is out of the box. You call one method or you implement something in the UI and it just magically works.
The only thing that you've got to do custom development on are your features, the things that make your development unique. In SharePoint, we design differently. We design for reusability. We build components, both visually and internally, that are smaller than we might build in a regular .NET application. Our goal is always to create a solution but we do that by using smaller components that are made of code but there then configurable. And this allows us to change the way that they're set up, the way that they're connected, and the way that they will display the content that we add in the solution.
Let's take a look at how SharePoint internally does this with some of its web parts. A good web part to start with is the RSS viewer. It's a blend between having a completely baked solution and something that is just a component that you can completely configure. It's designed to consume an RSS feed so the first thing that you have to do is configure it for where the RSS feed is that you want to consume. By the way, RSS is really simple syndication. It's the way that we provide news feeds.
Once you've configured the RSS feed, you can optionally configure the refresh interval so control the caching, the maximum number of items to be displayed and even the XSLT or the XML style sheet language transformations that can be used to change the way that the HTML is omitted out of the web part. Now the RSS viewer can be used to display industry standard news feeds or it can be used to display cotent that has been updated in SharePoint. SharePoint internally will generate these news feeds so that you can plug things together.
A slightly more generic form of this sort of web part and the way that we configure things is the XML viewer. The XML viewer web part, you still configure the source location of the XML, just like you would RSS, and now you have to provide a transformation because there's no default transformation is provided for you. And this solution is more broad because it can be used to do things like display pending calls in a queque from an interactive voice response system or an IVR.
You can use it to display machine status from machine automation. You can look at orders out of an ERP system. Anything that can generate an XML feed can be processed by the XML viewer, transformed by the XSLT, and displayed on a page with other information. I've been talking about configuration but I've not really distinguished between the different kinds. So let's do that now. Environmental configuration: these are the kinds of configurations that vary by environment, are typically stored in a web.config file.
And you can certainly do that with SharePoint. The problem with this is that it causes an application recycle every time you have to change it so there's a micro outage. SharePoint also offers you an opportunity to look at properties. Every object or nearly every objective inside of SharePoint has a property bag associated with it that you can jam things into. Then later your code can read out of it. The beauty of the properties is both that it doesn't cause a reset, so there's no outage when you change these configuration values but also that you can control the scope at which they apply.
So you may have one web application which needs to reach out and touch one sort of the ERP backend and a different web application on the same form that needs to reach out and touch a different one. You can configure those all with properties. The other kind of configuration is a per use configuration. It's the user configuration or the configuration of the site administrators, the not quite have access to the box sort of folks. These can be configured at a web part property level.
That's what we were looking at with RSS and the XML viewer. We were looking at WebPart properties that configure how it's used. This allows us to reuse the same web parts, sometimes even on the same page, for different purposes. All of this really gets to the idea that we're doing object-oriented programming for the user interface. In traditional development, we think of the way that we build in terms of a full page view. We think about it in terms of, well this is the order page or this is the search page or this is a whatever page it is.
Inside of SharePoint, we think in terms of web parts primarily. And web parts are these reusable components that can be added to the page, associated with one another, connected to one another so that one web part and another web part communicate. This communication allows us to build smaller components that can be aggregated and composited in different ways. As we finish this module, we need to think about the fact that there are lots of things you can do with SharePoint.
There are far fewer things that you actually should do with SharePoint. Certainly you can have a big person riding a small bike but that doesn't make a lot of sense. Ultimately what we want to see is we're using SharePoint where it adds value. Where the pedestal of APIs and integrations that it offers, delivers more value to your custom development than it takes to work around some of SharePoint's quirks and nuances. So we want to use SharePoint only for what it's good at.
If you've wanted to learn how to develop custom solutions on SharePoint—or you've been told that you need to develop a solution that integrates with SharePoint—this is the training you need. It's quick, to the point, and effective at helping new developers work with SharePoint code.
Robert Bogue shows how to create new web parts, access and update data in SharePoint, work with files, and create SharePoint artifacts: lists and libraries to store data, site-level features, files, etc. He also shows how to create sandbox solutions that do not affect the rest of the server environment, and discusses execution options for solutions, including in-page, quasi-page, and out-of-page execution.
- Developing a web part
- Connecting and configuring web parts
- Building sandboxed code
- Choosing an access method for SharePoint data
- Querying with CAML
- Fetching files
- Updating SharePoint data
- Creating and provisioning artifacts
- Executing long-running operations
- Tinkering with timer jobs
- Understanding SharePoint execution workflow