Differences Between Using the .NET Assembly Connector and Writing a Custom Connector

Applies to: SharePoint Server 2010

In this article
Using the .NET Assembly Connector
Writing a Custom Connector
Benefits and Disadvantages of the .NET Assembly Connector vs. Custom Connector
When to Use Each Approach

This topic describes when you should use the .NET Assembly Connector provided with Microsoft Business Connectivity Services (BCS) and when you should write a custom connector to connect to external systems not directly supported by Business Connectivity Services.

A custom connector is written to be agnostic of external content types that connect to a kind of external system (example, all databases or all Web services), whereas each .NET connectivity assembly is specific to an external content type. Also, a custom connector provides Administration user interface integration, but a .NET connectivity assembly does not.

Using the .NET Assembly Connector

When you use the .NET Assembly Connector instead of writing a custom connector, you do the following:

1. Write code as Microsoft .NET Framework classes and compile the classes into a primary DLL and multiple dependent DLLs.

2. Publish the DLLs into the Business Data Connectivity (BDC) service database.

3. Use Microsoft SharePoint Designer to discover the .NET Connectivity Assembly and create a model.

4. Map each entity to a class in the DLL, and map each BDC operation in that entity to a method inside that "Class".

At run time, when a user executes a BDC operation, the corresponding method in the primary DLL is executed.

Writing a Custom Connector

When you write a custom connector instead of using the .NET Assembly Connector, you do the following:

1. Implement ISystemUtility, IConnectionManager, and ITypeReflector interfaces (only ISystemUtility is mandatory). Potentially, one can also override default connection manager and EntityInstance interfaces. In addition, implementing IAdministrableSystem provides Administration UI property management support and implementing ISystemPropertyValidator provides import time validation of LobSystem properties (not on the Microsoft Office client).

2. Compile the code in step 1 into a DLL and place it in the global assembly cache on the server and clients.

3. Author the model XML for the custom data source (SharePoint Designer 2010 does not support a model authoring experience for custom connectors).

4. At run time when a user executes a BDC operation, this invokes the Execute method in the ISystemUtility class. Thus, the responsibility of executing the actual back-end method is given to the Execute method (as implemented by the custom connector).

Benefits and Disadvantages of the .NET Assembly Connector vs. Custom Connector

The following table lists the benefits and disadvantages of using the .NET Assembly Connector versus a custom connector.

.NET Assembly Connector	Custom Connector
DLL that implements business logic is stored in the BDC store. Therefore, you do not have to place the DLL separately in the global assembly cache on client and server.	Binaries that implement a custom connector must be placed in the global assembly cache on the client and server.
The .NET Framework DLL that implements business logic is deployed to thick client computers via ClickOnce based Business Connectivity Services deployment.	A separate setup process is needed to install binaries that implement a custom connector.
No administrator privileges are required on the client computer for deployment.	Administrator privileges are required on the client computer to put the assembly in the global assembly cache.
Taking external lists offline will work seamlessly because the required assemblies are deployed through ClickOnce.	Taking external lists offline breaks if client setup does not put the assembly in the global assembly cache.
Provides a useful approach if business logic can be exposed through static APIs that rarely change.	Provides a useful approach when back-end interfaces frequently change (are dynamic).
Does not provide facility to override the default TypeReflector (Business Connectivity Services component that interprets types as .NET Framework types).	Provides facility to override the default TypeReflector and implement a custom TypeReflector.
One-to-one mapping of the BDC entity and the .NET Framework class is required. Thus, if one BDC entity must aggregate multiple classes, a wrapper must be written. This requires recompiling and redeployment of the .NET connectivity assembly.	There are no such restrictions.
DLL interfaces work like a back end for Business Connectivity Services, thus the actual the back end is completely abstracted from the Business Connectivity Services stack. Because the .NET Framework assembly DLL is loaded in process with Business Connectivity Services, there are no security requirements. It is always considered as "Passthrough".	In the custom connector approach, different kinds of security mechanisms offered by Business Connectivity Services can be used, including a custom security mechanism (Business Connectivity Services natively supports RevertToSelf, Passthrough, and Credentials and WindowsCredentials).
Business Connectivity Services has tooling support for the .NET Assembly Connector both in SharePoint Designer (discovery) and in Visual Studio 2010 (development and deployment of the DLL and the model).	No tooling support is provided for custom connectors.

When to Use Each Approach

Both the .NET Assembly Connector and custom connector are highly valuable Business Connectivity Services connectivity extensibility mechanisms that are offered by Business Connectivity Services.

The .NET Assembly Connector approach is recommended if the external system is static. Otherwise, for every change in the back end, you must make changes to the .NET connectivity assembly DLL. This, in turn, requires recompilation and redeployment of the assembly and the models.

If the back-end interfaces frequently change, the custom connector approach is recommended. By using this approach, only changes to the model are required.