Generated code - WCF Data Services support

LLBLGen Pro Runtime Framework supports the WCF Data Services shipped by Microsoft. The support is for .NET 4, similar to WCF Ria Services support. LLBLGen Pro Runtime Framework comes with a full Data Service Provider implementation which makes it real easy to create your own WCF Data services based on a model in Adapter or SelfServicing code.

The WCF Data Services is designed to be usable with existing Visual Studio.NET tooling. The following information describes how to define a WCF Data Services for generated code in Adapter or SelfServicing. The example below will add a service for 'Northwind', using Adapter, however you can use the same code for SelfServicing.

Creating a WCF Data Services Tutorial

• The .NET 4.0 using VS.NET project which will host the WCF Data Services service has to have a reference to the following LLBLGen Pro runtime framework dlls:
  
  • SD.LLBLGen.Pro.ORMSupportClasses.NET20.dll
  • SD.LLBLGen.Pro.LinqSupportClasses.NET35.dll
  • SD.LLBLGen.Pro.ODataSupportClasses.dll
    
• The VS.NET project also has to have references to the generated code projects. For Adapter, you need to reference both projects.
• Code has to be generated for .NET 4.0
• To add a WCF Data Services service class, right-click the VS.NET project to which to add the service to in Solution Explorer and select 'Add -> New item…'
• Select under 'Web' (be sure to select .NET 4) the item WCF Data Service and specify a proper name for the file/service and click Add.
• This will add the necessary references for WCF Data Services and will add a yourservicename.svc file with associated yourservicename.svc.cs/vb file. Open the service's code by right-clicking it in Solution Explorer and selecting 'View code'.
• The service class derives by default from i. This has to be changed to LLBLGenProODataServiceBase<LinqMetaData>. The LLBLGenProODataServiceBase is in the namespace SD.LLBLGen.Pro.ODataSupportClasses (so you have to add a using/imports statement for that namespace at the top of the file, use the smart-tag in the VS.NET editor for that). The LinqMetaData class is in the generated code of the model you want to expose through the service. This class is in the namespace Rootnamespace.Linq, where Rootnamespace is the namespace you specified when you generated code in the designer.
• The service, which we've called NorthwindService, now looks something like this: (in red the changes are specified you have to make.) Note that RootNamespace is the root namespace of your generated code.

using System;
using System.Collections.Generic;
using System.Data.Services;
using System.Data.Services.Common;
using System.Linq;
using System.ServiceModel.Web;
using System.Web;
using SD.LLBLGen.Pro.ODataSupportClasses;
using RootNamespace.Linq;

namespace MyNamespace
{
	public class NorthwindService : LLBLGenProODataServiceBase<LinqMetaData>
	{
		// This method is called only once to initialize service-wide policies.
		public static void InitializeService(DataServiceConfiguration config)
		{
			// TODO: set rules to indicate which entity sets and service operations 
			// are visible, updatable, etc.
			// Examples:
			// config.SetEntitySetAccessRule("MyEntityset", EntitySetRights.AllRead);
			// config.SetServiceOperationAccessRule("MyServiceOperation", ServiceOperationRights.All);
			config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
		}
	}
}

• For development it's key to add the following attribute to the service class, so exceptions are returned in full to the client. It's recommended this attribute is removed when the service is in production:
  
      [ServiceBehavior(IncludeExceptionDetailInFaults = true)]
  
• In the InitializeService method, you can add additional configuration options. For example to be able to fetch all entities, add:
  
      config.SetEntitySetAccessRule("*", EntitySetRights.AllRead);
  
  It's also recommended to add config.UseVerboseErrors=true; to this method during development.
• There are three methods in the service class which have to get an implementation. They're specified below in code and are simply factory methods. In comments, selfservicing variants are given.

protected override LinqMetaData CreateLinqMetaDataInstance()
{
	// adapter
	return new LinqMetaData(new DataAccessAdapter());
	// selfservicing:
	// return new LinqMetaData();
}

protected override ITransactionController CreateTransactionControllerInstance()
{
	// adapter
	return new DataAccessAdapter();
	// selfservicing:
	//return new Transaction(System.Data.IsolationLevel.ReadCommitted, "Trans");
}

protected override IUnitOfWorkCore CreateUnitOfWorkInstance()
{
	// adapter
	return new UnitOfWork2();
	// selfservicing
	// return new UnitOfWork();
}
	

• You have to specify an override to the property ContainerName, which should return the name of the service. In our example this becomes:

protected override string ContainerName
{
	get { return "NorthwindService"; }
}

• Optional: you can specify an override to the property ContainerNamespace. By default it uses the namespace of the LinqMetaData type, but it's recommended to specify a namespace which makes sense in the context of the service, as this namespace is used for the entities returned from the service, e.g. you can use the namespace or name of the project containing the service.
• Optional: If you're using ORM Profiler, add the call to the interceptor to the InitializeService() method.
• The VS.NET project containing the service needs to be able to read the connection string. It's therefore key to add the connection string for the generated code to the project's app.config or web.config file.
• The service is now ready to use. To the service file you can add WebGet methods and other methods, e.g. methods annotated with QueryInterceptor attributes.
• To test the service, compile and start it. If you have added the service to a Website application, you can simply start the service by requesting it from a web browser. To see whether the meta-data is fully obtained, append $metadata to the service URL.
• See http://www.odata.org for details about using WCF Data Services.

The easiest way to consume the service in a .NET application is to add a Service Reference (in VS.NET) of the service you just created. This way VS.NET will generate classes for you, one for each entity exposed by the service and a context class to work with the entity classes on the client.

Using JSONP with the WCF Data Service

If you want / have to use JSONP with the data service, e.g. because a control used on the client requires JSONP support in the WCF Data Service, please follow the following steps:

• Download the JSONPSupportBehavior.cs code file from http://archive.msdn.microsoft.com/DataServicesJSONP. (under downloads)
• Add the file to your WCF Data Services service VS.NET project
• Add the [JSONPSupportBehavior] attribute to the WCF Data Services service class you wrote (e.g. by following the steps mentioned in the tutorial above.

After this, the service is capable of handling $callback and $format elements properly and is able to handle and return JSon.

Limitations

We did our best to support WCF Data Services in full to make sure everything in your LLBLGen Pro model/generated code is exposable through the service. However as it turned out, WCF Data Services in its current version (.NET 4 framework) has limitations and these limitations can make it a problem to expose the generated code through a service, even though the generated code works OK when used in normal .NET code. These limitations are described below.

Most of them will result in an error either when you obtain the $metadata or when you fetch data. If you run into one of these limitations, it's best to create a copy of the LLBLGen Pro project file and remove the entities/fields/types which cause a problem and re-generate the code, and use that in the service. If that's not doable, please look at WCF Ria Services instead. This other framework is also supported by LLBLGen Pro and has less limitations (but also less features in some areas).

No enum / DateTime2 etc. support

As WCF Data Services builds an entity data model (EDM), the types are based on the EDM type system. This means that it can't deal with fields which have an Enum type. The LLBLGenProODataServiceBase class filters out fields with Enum types and all other types which aren't mappable to an EDM type. These fields don't show up in the entity exposed by the service. The types which are supported are listed in the list of DataTypes on this page: http://msdn.microsoft.com/en-us/library/dd723653.aspx. Our provider doesn't use the Reflection provider, but the same list of types applies.

No byte[] type support for PK fields.

A field in the primary key of an entity isn't allowed to be of type byte[]. This is a limitation of WCF Data Services, and a left-over from Entity Framework, which has the same limitation.

No navigators supported in subtypes.

This is a limitation of WCF Data Services in .NET 4. A future version of WCF Data Services will support this, and when this is released we'll look into lifting the filters we added to our code to filter out navigators on subtypes. This limitation means that if you have inheritance in your entity model, any subtype can't have a relationship with another entity, all relationships have to be defined on the root of the hierarchy. This is quite a limiting factor for many people. If you run into this, consider WCF Ria Services instead (or a normal WCF service).

Many to Many relationships are single sided and read-only

In LLBLGen Pro, many to many relationships are always read-only and this won't change in a WCF Data Service. To update many-to-many relationships, you have to append entities over the intermediate entity and the 1:n/m:1 relationships instead, like you'd do normally when using LLBLGen Pro code.

Paging support uses Skip/Take and have to be in page size blocks.

Paging is done through Skip/Take methods in Linq, and as LLBLGen Pro has paging per page, the .Skip(n).Take(m) combination has a limitation: n has to be 0 or more multiplications of m. So .Skip(9).Take(3) works, but .Skip(9).Take(4) doesn't, as the skip value is used to calculate how many pages to skip.

Acknowledgements

We'd like to thank Brian Chance for his work in this area. His templates (which used the RelfectionProvider) to bring WCF Data Services support to LLBLGen Pro were a great source of information during the development of the data source provider.