by Steve Fox
When I think developer platform, my baseline requirements are solid tool support, a good cadre of out-of-the-box (OOTB) features that I can leverage, and a robust set of APIs. Although Microsoft SharePoint has historically fulfilled these baseline requirements, I think there were places that caused a bit of a stutter when issuing the words developer platform—especially if we reach as far back as SharePoint 2003 technologies. As SharePoint has evolved, however, it has become a force not only as a collaboration technology but also as a developer platform. As a testament to its success, SharePoint 2007 technologies, which includes Microsoft Office SharePoint Server (MOSS) 2007 and Windows SharePoint Services (WSS) 3.0, have managed to tip the license scale at greater than 100 million licenses to date and a developer community of approximately 600,000 people who are increasingly using it as a platform on which to build their solutions. SharePoint 2007 is about to be succeeded by SharePoint 2010, which will bring you to a place where the words developer platform will become a natural part of your SharePoint conversation. In short, SharePoint 2010 is a first-class platform.
Why SharePoint 2010 Is a First-Class Developer Platform
Over the past year, I’ve been spending quite a bit of time with SharePoint 2010, and from what I’ve seen there’s been a great evolution forward. For example, you’ll often hear SharePoint 2010 described in the context of developer productivity, rich platform services, and flexible deployment, and each of these three ways of describing SharePoint holds its own meaning. That is, developer productivity describes the new tooling associated with the platform and the fact that SharePoint 2010 ships in-box with Visual Studio (VS) 2010; rich platform services represent the wealth of APIs, services, UI changes, and the like that provide a new programmatic experience for developers; and flexible deployment describes how developers can manage their source code across teams, deploy their solutions on-premises or to an online instance of SharePoint, and import and deploy to a SharePoint farm using a common Web Service Provider (WSP) standard.
All the above notwithstanding, there are four key areas I feel will have an incredible impact, both from a developer standpoint and from a marketplace and adoption standpoint. These areas are: tools support, data programmability, services support, and sandboxed solutions.
Developer Tools Support
In the past, there have been multiple, disconnected ways to build and deploy solutions to SharePoint. For example, STSDEV and VSeWSS are both VS add-ons that provide developers with the ability to build and deploy to SharePoint 2007. You could also just create a VS 2008 project from scratch, create a DLL and a feature folder structure, and deploy to the server with some post-build events. Further, SharePoint Designer provides some functionality around master page and page layout editing as well as rules-based workflow. The point is, there was no one rally point for developers to develop solutions for SharePoint. With SharePoint 2010 the tooling story gets much better.
VS 2010 has a number of project templates you can use for SharePoint development. For example, you can import and redeploy WSP packages using the Import SharePoint Solution Package template. You can also create an Empty Project, then add Web Parts or event receivers from the available item-level templates. Further, you can create a Business Data Catalog (BDC) model and connect SharePoint to line-of-business (LOB) systems programmatically. You can also add workflow by using either the State Machine Workflow or Sequential Workflow templates. These are only a handful of the templates available. Figure 1 shows other available templates.
If it’s not obvious why the tooling is important, the fact is that having the tools right in front of you makes getting started easier. The tooling also standardizes (to a certain degree) the way in which developers work with SharePoint and streamlines how the community learns how to develop against SharePoint. I say “to a certain degree” because there will certainly be a place for SharePoint Designer 2010 and the Expression Blend suite. For example, SharePoint Designer will continue to be used in the area of workflow development and LOB integration, and developers will use Expression for UI design when integrating Microsoft Silverlight and SharePoint. But, for core SharePoint development (i.e. features, web parts, and so on) VS 2010 will be the main point of entry.
Data Programmability
Before you start the coding process, you need some understanding of what you’re going to code against. Be it data or service-oriented back-ends, SharePoint 2010 provides what I would argue is game-changing data programmability in a couple of areas.
The first area is the evolution of the BDC functionality from SharePoint 2007 to the Business Connectivity Services (BCS) in SharePoint 2010 , which allow developers to move from read-only views of their back-end data sources to read/write interaction with that data in SharePoint 2010. This read/write support extends from the integration of simple data constructs, such as in-memory business objects or relational data structures, to more complex data, such as LOB data from SAP, PeopleSoft, or Microsoft Dynamics. The read/write capability provides not only an opportunity to evolve SharePoint further into the enterprise, but it also enables other types of LOB system integration. For example, let’s say you want to hook your SAP data into SharePoint. You can use Silverlight (in which mapping data to controls is easy once you have a data construct), the BCS (which has a programmable API), and the list architecture to deploy a full LOB application to your SharePoint instance. The result is a dynamic external data list that you can deploy to any SharePoint instance and one that is read/write, as Figure 2 shows. And you can use either SharePoint Designer 2010 or VS 2010 to create the BCS interface with your LOB system. The result is the same: a tightly-knit and dynamic integration with your back-end LOB system.
The second area of improved data programmability is the abstraction of Collaborative Application Markup Language (CAML), which is the primary way to query list data. With SharePoint 2010, the need for CAML gets abstracted through the use of Language-Integrated Query (LINQ) for SharePoint. For example, the code snippet in Listing 1 shows the setting of context using a specific SharePoint site, the creation of an EntityList object, the use of LINQ to query against the customer’s data, and then the binding of that data to a grid control.
After you’ve retrieved the data, you can execute custom queries against that data through LINQ for SharePoint as the data coming from SharePoint can now be treated as strongly typed objects. Thus, you rarely have to use CAML to query the data within SharePoint.
Services
One key way to integrate non-Microsoft systems and the wider web is to use a web service. In SharePoint 2007, there were several ASP.NET web services (ASMX ) that let you interact with lists and other parts of SharePoint. Although the support for these services persists forward, SharePoint 2010 now supports WCF and REST-based services. Microsoft has been leading developers down the WCF path for quite some time, and although it’s trickier to use than ASMX services, you have more granular control over your service contracts and implementation. With WCF support, developers can begin to build and integrate custom WCF services with SharePoint. Further, REST-based services let you interact more easily with list data. REST-based services also let you interact with SharePoint data from multiple clients, such as Microsoft Office smart-client applications, Silverlight applications, or even Windows Presentation Format (WPF) applications.
his use of web services is important because it opens up the developer’s options to begin to think about integration and scope beyond just the SharePoint domain and makes the job of implementing the integration easier. In reality, companies invest a lot of money in disparate systems, and services provide a cogent way to bring those systems into conversation with one another and into the purview of the information worker experience.
Sandboxed Solutions
The last area to discuss lies in the area of deployment—specifically, sandboxed solutions. Sandboxed solutions are SharePoint solutions that you deploy as partial-trust applications and can run without farm-level administrator intervention. For example, you create a web part that has some custom ASP.NET controls that provide a simple sales forecast calculation, and you want to deploy it to your team site within the organizational site collection. However, you’re not the administrator. Using sandboxed solutions, you can create your web part as a partial trust application and deploy it to your site. The partial-trust web part gets deployed into a special Solutions Gallery, from which you can activate the web part and add it to your web-part page. Figure 3 shows a sample web part that was created, deployed, and activated within the Solutions Gallery.
Sandboxed solutions let you deploy your application to your SharePoint site without administrator intervention, so they’re a significant time and resource saver and gives you more control over the custom code that is deployed to your site. You can also deploy your applications to SharePoint Online. Given the level of desire for developers to have more control over their sites, and the increase in adoption of SharePoint Online, I would argue that sandboxed solutions will be a common way to deploy solutions to SharePoint.
Ramping Up for SharePoint 2010
With SharePoint 2010 arrives a great set of OOTB features; tooling support that is native to VS 2010; and a much-improved object model, services, and API story. I’ve discussed four of the improvements that are particularly appealing to me. I believe these four areas will greatly contribute to SharePoint development, but represent only a percentage of what you can do with SharePoint in the 2010 release. Collectively, these make spending the time ramping up your SharePoint skills time well spent.