3

I'm cooking up some spatial examples and have decided to give Dapper a go, although EF has spatial support, and I'm loving having control over my SQL again (Thanks Sam & Marc).

However, I need to be able to have POCO's that support the DbGeography class. For example :

public class BuriedTreasure {
   public int PirateId { get; set; }
   public DbGeography MarksTheSpot { get; set; }
}

My Google foo has been letting me down and the closest match I can find is this question, though it only caters for adding spatial support as a parameter (so it's 50% there).

Now as far as I can see I'm limited to the following options of which neither to me is a viable solution.

  1. Customize the dapper code to understand a SQL Server specific type
  2. Specify LONG, LAT & ELEVATION decimals in my POCO and create the SPATIAL type in my stored procedure and have another procedure to retrieve the values (or use a persisted computed column but that's nearly the same)

Alternatives?

Community
  • 1
  • 1
Ruaan
  • 180
  • 1
  • 7

1 Answers1

1

For anyone interested, essentially I went for option 2 in the question I posted above. I have my spatial data mapped to decimals. The stored procedure does some additional checking so it was easy to construct the point therein, ie the following snippet :

Yarrrr = geography::Point(@Latitude, @Longitude, 4326)

Essentially, the DbGeography class is immutable, goes to show... RTFM :)

No changes to dapper required at all!

Ruaan
  • 180
  • 1
  • 7