SharePoint Developers Must Know Business Connectivity Services

If you call yourself a SharePoint developer, you’ve almost certainly encountered Business Connectivity Services. BCS is part of the Composites workload in SharePoint 2010 where integration between SharePoint and other systems is centered. BCS demonstrations are common at every SharePoint conference, training class, and user group.

The typical BCS presentation shows how to integrate systems such as CRM and ERP with SharePoint. Demonstrations involve a no-code solution created in SharePoint Designer that rapidly integrates external data, creates an external list, and synchronizes that list with Microsoft Outlook. List items are then edited in both SharePoint and Outlook, and the changes reflected in the back-end database.

Although these demonstrations fit easily in an hour and certainly look sexy, they can mislead developers. BCS should not be thought of as simply middleware to use with existing systems; it should be recognized as the data layer on top of which many SharePoint applications can be built.

SharePoint developers often discuss the differences between lists and databases. Lists are great for creating data structures that are easily editable by end users, but they lack the storage efficiency offered by databases, and lists have limitations in the number of items that can be displayed before degrading the performance of page loads. So lists aren’t always the right choice for storing data for SharePoint solutions. The key point here is that the list-versus-database discussion isn’t about existing systems—it’s about new solution development.

So what if you’re trying to create an application that needs the capacity and efficiency of a database for storage, but you want it integrated with SharePoint in a way that’s familiar to end users? In the past, developers often simply created ASP.NET applications and deployed them to the LAYOUTS directory or built custom Web Parts that connected directly to a Microsoft SQL Server database. These approaches work, but they have some drawbacks.

In my opinion, ASP.NET applications are anathema. I recognize that this method is widely used, but it strikes me as lazy because the ASP.NET developer never really has to learn SharePoint. Furthermore, most of these applications never operate in a SharePoint context. Sure, they look like they’re in -SharePoint, but most never reference the Microsoft.SharePoint namespace or get a SPContext object. Therefore, there’s no real integration—it’s just an illusion.

Custom Web Parts are better; by their very nature, they operate in a SharePoint context. The problem with Web Parts is that they’re typically designed with little separation between the data layer and the UI. Additionally, the developer has to figure out where to keep the connection string information; everyone knows the nightmare of managing too many application properties and connection strings in the web.config file.

BCS changes all of this. BCS offers the ability to connect SharePoint solutions to databases (as well as web services) through a layer designed specifically to support application development. Like all good data layers, BCS separates the data source from the business logic and UI. The BDC metadata model provides this separation layer and lets SharePoint developers create UIs using lists, ASPX forms, InfoPath forms, Web Parts, field controls, and application pages without any changes to the underlying model, ¬making maintenance much easier.

BCS also provides configuration, throttling, and security for free. Configuration values, like connection strings, can be kept in the resources file for a model. A separate resource file is easily managed for each environment. SharePoint security is used to grant access to the model and underlying operations.

Because BCS offers an integration layer capable of connecting SharePoint to external data, developers should consider it as the primary pattern for developing applications in SharePoint. If your SharePoint solution needs data storage with capabilities beyond those of a standard list, you should use BCS. You’ll be rewarded with a host of capabilities that a custom ASP.NET application will never have, such as enterprise search, external data columns, user profile integration, and more. And that’s why every SharePoint developer must know BCS.