Developing Custom Screens for SharePoint 2010

When building a SharePoint site, you may find yourself having to build custom screens. This may be because you need to integrate with a third party system, or perhaps your users require a more sophisticated user interface than can be provided out of the box.

There are a few (non exhaustive) options around building custom screens in SharePoint 2010, and I have created them on the basis that you need to read and write to some tables held in a separate SQL Server instance.

There is no conclusion to the best method. You should always consider your business requirements in determining which is most appropriate.

This is also assuming that you have to use SharePoint as a platform instead of ASP.NET.  (At least for Options 1 & 2)

Option 1: Custom .NET WebPart + Services

For total flexibility, you can create a custom web part with any kind of experience you like.  You can employ AJAX, Javascript and third party UI components such as Infragistics or Telerik.

The seperate service layer allows you to abstract your data access code away from your User Interface. The additional benefit is that your service layer can take advantage of .NET 4.

Advantages

  • Implement any user interface you like
  • Abstract data access / business logic away from user interface
  • Easier to secure (no database connections in web site web.config)
  • Easier to unit test web services
  • Leverage .NET 4 in your service layer

Disadvantages

  • Requires more coding for extra layer

Option 2: Custom .NET Webpart + Direct Access

This is the same as Option 1, with the Service Layer removed.

Advantages

  • Implement any user interface you like
  • Faster to develop.

Disadvantages

  • Restricted to .NET 3.5
  • Database connection strings in SharePoint web.config
  • Harder to unit test User Interfaces than abstract services.

Option 3: JavaScript + SharePoint REST Services

SharePoint 2010 can now expose all of its lists through a REST API. This combined with External Data Sources make SharePoint a good web service provider.

The idea is that the whole User Interface can be built with JavaScript ( and JQuery ), that can easily consume and update data through the SharePoint REST API.

The JavaScript is hosted in a content web part, although a Visual Web Part may give you more flexibility for this.

Advantages

  • No .NET coding required, just JavaScript / JQuery
  • Easy to configure SharePoint to do this
  • For a large number of end users, this approach will be far less demanding on the SharePoint server. (All User Interface processed on the client machine).

Disadvantages

  • All User Interface is managed on the Web Browser
  • Permissions to read / update / delete data are manages far down in the database
  • Harder to build event driven logic in JavaScript than ASP.NET
  • All JavaScript can be read by the end user. Hacking may be possible.

Option 4: InfoPath

SharePoint 2010 can host InfoPath forms inside the browser. This combined with External Data Sources means you can very quickly create a user experience on top of external data.

Advantages

  • No .NET coding required, just define InfoPath forms
  • InfoPath rules are easier/safer to implement than .NET business logic
  • Easy to configure SharePoint to do this
  • Ideal for simple operations such as filling a table with data.

Disadvantages

  • Little control over the User Interface and the controls you want to use (few custom development options)
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s