2010-07-16 95 views
2

我的公司对所有SELECT操作使用存储的特效,所以它使我很难创建合理的导航属性。不管他们是否懒惰加载,我在这一点上都不太在意。在.NET实体框架中使用SP添加自定义导航属性4

因此,例如,我为Customer创建了一个实体,然后创建了一个FunctionImport来映射GetAllCustomersSP以返回Customer实体的集合。但我想要在每个客户实体上有一个导航属性“订单”。

但是,如果我使用Customer实体partial class来添加此属性,问题是我无法访问原始上下文,因此我无法显式或延迟地调用GetCustomerOrdersSP。

我能看到的唯一选择是修改我的存储库以显式添加这些属性,这看起来很蹩脚,因为它将实体逻辑放入存储库。

有什么我在这里失踪?我可以在实体模型设计器中看到,我可以指定自定义插入,更新,删除SP,但我没有看到使用选择SP实际检索数据的任何方法。

+0

有没有人有这方面的见解? – kpozin 2010-08-23 19:23:41

+1

使用SP与ORM结合使用并不是理想的情况,有时,当您仅限于使用SP时,最好遵循更传统的DTO数据策略。 – 2011-03-06 20:32:21

回答

1

我在这里同意Tim的观点......您提出的任何解决方案都不会充分利用ORM,并且会成为潜在的噩梦。我建议在代码中创建一个模型,并以您想要开发的方式进行构建。

在应用程序的数据访问层中,可以映射使用SP的数据对象以保湿模型对象(查看AutoMapper)。你的应用只会知道你的模型对象。

这样做会为您提供与对象交互方式的一致性,并且您可以开始对允许更细粒度访问表的权力施加压力,在这一点上,您可以调整数据接入层支持EF并删除SP。此时,您可以考虑将您创建的对象迁移到通过EF持久保存的POCO对象。

我们遇到过类似的问题,因为授予原始数据库访问权限为“禁止”。我们通过使用一种模型克服了这个问题,在该模型中,我们只授予对表的访问权限,而不是整个数据库,并确保EF使用参数化SQL的DBA,从而消除了SQL注入的担忧。