我有一个使用 sqlgeography 的实体/表。
由于 EF 4.X 不支持空间类型，我改为来回发送字段的字节。
我在数据库端存储了处理转换的过程，并在代码端存储了属性来完成这项工作。
为了在代码中添加属性，我使用了分部类。
这些属性之一是用于 SqlGeography 的，它简单地包装了 byte[] 属性来处理获取和设置。
使用 NotMappedAttribute 对 EF 隐藏此属性。
另一个是公开 byte[] 本身的属性，并用 EdmScalarPropertyAttribute 和 DataMemberAttribute 进行修饰。
然后，我转到 EF 模型设计器 (*.edmx) 将实体模型指向插入/更新/删除存储过程。
它找到正确的存储过程并意识到它们（在适当的时候）采用 VARBINARY 参数。
它还具有一个下拉列表，允许您选择实体类上映射到该参数的属性。
然而，这个下拉列表没有列出我的任何一个属性。我不关心 SqlGeography 属性，因为它对 EF 是隐藏的，但是能够将其指向 byte[] 属性对我来说至关重要，因为这就是数据的来源。
我非常希望避免使用数据库触发器或包装类和附加字段来伪造此工作。
我尝试手动编辑 .edmx 文件以包含 byte[] 属性，但随后它只是抱怨它未映射。
谁能给我一些关于如何让它发挥作用的见解？或者达到最终结果的替代方法？
I have an entity/table that uses sqlgeography.
Since EF 4.X doesn't support spatial types I'm instead sending the bytes of the field back and forth.
I have stored procs on the database side that handles the converstion and properties on the code side to do that job.
To add the properties in the code I used a partial class.
One of those properties is for the SqlGeography which simply wraps around the byte[] property to handle getting and setting.
This property is hidden from EF using the NotMappedAttribute.
The other is the property exposing the byte[] itself and is decorated with the EdmScalarPropertyAttribute and DataMemberAttribute.
I then go to the EF model designer (*.edmx) to point the entity model at the Insert/Update/Delete stored procs.
It finds the stored procs alright and realises that they (when appropriate) take a VARBINARY parameter.
It also has a drop down allowing you to select a property on the entity class which maps to that parameter.
However this drop down doesn't list either of my properties. I don't care about the SqlGeography property since that is meant to be hidden from EF, however it is vital for me to be able to point it at the byte[] property, as that is where the data comes from.
I would very much like to avoid database triggers or wrapper classes and addiitonal fields to fudge this in to working.
I tried manually editing the .edmx file to include the byte[] property, but then it just complains it's unmapped.
Can anyone give me some insight in to how to get this to work? Or an alternative method of achiving the end result?
发布评论
评论（2）
我们可以使用视图来创建二进制字段，但这需要手动为数据内的关系创建大量 xml。
这几乎违背了使用 EF 的目的，即让生活变得简单和轻松。
对于这个项目，我们只需向表中添加一个二进制字段，然后使用存储过程来处理服务器上的转换，并在部分实体类中添加一个属性来公开模型中的地理类型。
我怀疑下一个项目我们会使用 EF。即使涉及更多的代码编写，Dapper 也轻松得多。
如果有人认为它适用于他们，这里是使用视图的链接：
http://thedatafarm.com/blog/data-access/yes-you-can-read-and-probously-write-spatial-data-with-entity-framework/
http://smehrozalam.wordpress.com/2009/08/12/entity-framework-creating-a-model-using-views-instead-of-tables/
We could use a view to create the binary field for us, but this then involves manually creating a lot of the xml for the relationships within the data.
This pretty much voids the point of using EF which is to make life simple and easy.
For this project We'll just add a binary field to the table then have sprocs to handle the converstion on the server and a property in a partial entity class for exposing the geography type in the model.
Next project I doubt we'll be using EF. Dapper is so much more painless, even if theres a touch more code writing involved.
Here's the links for using views if anyone thinks it would be applicable to them:
http://thedatafarm.com/blog/data-access/yes-you-can-read-and-probably-write-spatial-data-with-entity-framework/
http://smehrozalam.wordpress.com/2009/08/12/entity-framework-creating-a-model-using-views-instead-of-tables/
最后，我们为每个表创建了一个计算列，将空间数据公开为字节。
然后，我们使用存储过程来插入和更新空间数据。
In the end we created a computed column for each table that exposes the spatial data as bytes.
We then use stored procs for inserting and updating the spatial data.