What is Sharepoint development from a developers point of view?

I hear a lot of talk about Sharepoint these days, but I'm having problems grasping exactly what it is through all the enterprise and marketing jargon. Trying it out hands-on seems too much of a hassle as well (several heavy software packages that you can't just download for free).

Could someone give a good developer-to-developer description of what Sharepoint is? I'd especially like to know wha开发者_如何学编程t Sharepoint developers generally do.

== Edit 2017 ==

This is a fairly old post and SharePoint have changed a lot the past years. Most parts of the original post are still valid but some would only apply if you do on premise installations where the future of SharePoint seem to lean towards SharePoint Online. That being said, most functionality are still there with some improvements.

== Original post ==

SharePoint is a very complex CMS (Content Management System) with a lot of nice BSS (Business support system) features. There are so many advantages of it that it's hard to limit what to mention. However, some of the obvious stuff would be that you can mix so many "environments" at the same server, these environments are separated as sites.

What do I mean by environments?

Let's say you run a logistics company and are sick of having so many different systems just to keep your business up and running. Many of the systems also have different providers so the ecosystem around the company gets equally complex as well, here comes SharePoint to the rescue since it's a system that actually can host all required environments. In example.

• External web page, hosted either by SharePoint or by an integrated web page
• Order management
• Customer support and ticketing
• Item handling of freight
• Intranet sites with document management

Each and every of these environments can benefit from SharePoints built-in features like workflows and custom content types.

I'd say that the foremost reason to choose SharePoint would be it's versatility of storing different types of data. It's not a system to choose if you are planning one million transactions each second even if the performance can be greatly upgraded with several servers in a farm.

My point of view as a developer is that SharePoint is pretty much all about the lists, libraries and the metadata store since it's where most of the data is kept. This is something you need to learn and to understand how to structure your data and how you'll implement your information model.

The most common assignment in my world would be integration SharePoint with an external CMS, like EPIServer or Joomla, to set up an integration where the visitors shall be able to send messages from the web directly into SharePoint. These assignments then trails into creating a workflow what will happend with this message when it's received by the customer support / sales staff or whatever, all the way until the errand can be closed. When done with this I might build some graphs in a custom web part using mschart displaying some sales data or statistics of support errands. Currently im planing the data structure using SharePoint as a webshop. And there you go again, versatility!

There is also a very powerful API in SharePoint if you are into integrations. I am myself involved in the production of an ADO.NET Connector for SharePoint which turns SharePoint into a SQL server enabling developers to skip using CAML. And, there are plenty of other cool tools out there.

Let's not forget the second biggest advantage of using SharePoint. You can focus on forward development, the backend is already there.

Here's a short video describing SharePoint from an end user/business perspective http://www.youtube.com/watch?v=s12Jb5Z2xaE

From a developer perspective, SharePoint is a platform that sits on top of ASP.NET that provides the services described in the video (and more). The job of the developer is to extend the platform when the out-of-the-box features alone cannot solve a business problem.

While SharePoint sits on top of ASP.NET, development for SharePoint differs from ASP.NET development in many ways. SharePoint uses lists as its primary storage mechanism, it has its own component model (Features), it has its own packaging and deployment model (Solutions), and so on. It does take some time to become proficient at being a SharePoint developer, even for someone who is skilled in ASP.NET development.

SharePoint comes with a lot of extendable parts that you can build on. You don't have to write your own authentication, workflow, load balancing, site theming, document versioning etc.

This lets you build high level solutions quickly.

In fact, the first question you should ask as a developer is if a problem can be solved without coding. Business users & admins can compose solutions within the browser or using SharePoint Designer. A developer should try to become very familiar with the work those roles have and the tools they use. Often you'll be the admin of your own development server which will expose you to AD, PowerShell and installation and configuration tasks.

If Visual Studio is needed, the code you develop will have to conform to SharePoint's frameworks, and use things like the Server or Client Side Object Model, various Xml schemas etc. in addition to html, JavaScript and C#. For example, instead of creating a straightforward page (as an ASP.NET dev might) a SharePoint solution may require you to wrap your html/js in a WebPart which can than be reused and configured in different pages by business users.

Hosted versions of SharePoint (esp. 2013) add another dimension to SharePoint development: besides html/js you may want to use Azure.