共用方式為

Spatial Types in the Entity Framework

  • 發行項

This post has been removed.

Visit msdn.com/data/ef for the latest information on current and past releases of EF.

For Spatial Support in Code First see https://msdn.com/data/hh859721

For Spatial Support in the EF Designer see https://msdn.com/data/jj250903

Comments

  • Anonymous
    May 04, 2011
    Is this being designed with other DB providers in mind? Oracle for example has Spatial support as well and is now supporting EF. Will they be able to "plug-in" and provide Spatial support as well? Thanks.

  • Anonymous
    May 04, 2011
    Our design will enable other DB providers to provide spatial support.  If they do so, the EF spatial support will light up for them.

  • Anonymous
    May 04, 2011
    I will absolutely be using these in both my existing HTML5 mapping apps as well as changing around existing work on an HTML5 book for Manning to support this shift. I like the canonical implementation of the OGC methods. This will keep us from having to add a bunch of additional references to the project. Regarding more specific types, everything helps coming out of the system but there will still be conversions anyway so just getting the calculations as functions is a great start!

  • Anonymous
    May 05, 2011
    The main point is that your implementation should allow third party EF-providers for other databases to use arbitrary end .NET types for working with spatial types. Otherwise, classes like DbGeometry and DbGeography should not reside in SQL Server-specific assemblies and namespaces - they should be available in base .NET/ADO.NET or EF assemblies.