How to use SQL Spatial Data with WCF ODATA Spatial
Mar 10, 2013 • Qian Li
Note: The below code is extracted from a working Windows Azure project on Visual Studio 2012. You may need to adapt it for your purpose. A quote with our contribution in your code will be highly appreciated.
Abstract
With the emerging demand of “Global Monitoring” and the introduction of new embedded technologies, the vision of Internet of Things is increasingly becoming a reality. This will lead to infrastructures that support the deployment of billions of sensors and carry Petabytes of data from these sensors to consumer applications.
Developing such solutions in a scalable and robust manner through heterogeneous pre-existing networks and systems is a challenge. Companies face distracting, time consuming and misplaced investments when trying to address all these problems at once, often failing to deliver their solution to the market, not because of the technology itself but due to the need of supporting infrastructure.
A common scenario we will be looking into in this article consists in using OData in conjunction with a SQL-based backend, leveraging Odata Spatial Model and SQL Spatial Type.
One of the goals of OData and .Net underlying frameworks is to offer a robust end to end solution to fulfill these issues.
According to OData, one of the key features of the next global solutions, is common spatial properties which include time and geography. To implement this feature, Odata v3 supports the Spatial Model.
On the backend side, SQL Server provides a Spatial Type, which is well distributed and already widely used.
However, when using Spatial Model, a gap appears in the flow of service as the OData spatial types are not cross compatible with the SQL Spatial library. Any attempt to build a WCF service against Entity with SQL data will fail with gentle kind of “not compatible type” message.
This short article will show you a trick to fill this gap as shown in the previous diagram.
Wrapping the Geography data Model
First we have to define wrappers which define a common data model for both types. We use the explicit and implicit operator to achieve this.
For the Geographic Point:
Exposing the Services
After this, we need to define a service model which deals with the Entity framework and WCF tools.
On the Entity framework view, we set the [NotMappedAttribute] to the wcf_location property.
On the WCF view, we set the [IgnorePropertiesAttribute] to the location property.
Each property has the same wrapper model, which makes the cast with the implicit operator.
This allows to implement each Wrapper type as needed in your own services.
Implementing the entity
Because we want to show some changes to the code, we chose to code the entity from the ground up. But you can generate the DBContext using Entity tools and edit it later. Remember that when using the Entity tool, all your changes to the generated code will be lost when you update the DB model.
If you want to add write capabilities, you need to add the support of the IUpdatable interface which is a bit complex.