EF中不支持自定义查询返回IEnumerable吗？不会这么弱吧？

garfieldzf 2013-09-09 04:50:59

项目中用的NH，加上现在关注的EF，都存在自定义查询的实体问题，也就是自定义查询时需要创建一个业务实体，那么这样的话尤其是对于数据管理平台来说Model层会相当庞大，我就体会到了。

今天在萧秦的博客中发现他用到了这个方法，即直接返回IEnumerable<dynamic>，经请教后，他说用的是fluent Data ORM, 这个ORM是支持dynamic的，那么我就奇怪难道EF真的不支持。
我写了个测试代码，发现，如果在EF中这样使用，其实dynamic就被理解为object. 看看大家遇到过累死的烦恼没？



  string sql = @"select a.ID as FID,a.MODULENAME as FMODULENAME,a.ICON as FICON,b.ID as CID,b.MODULENAME as CMODULENAME,b.ICON as CICON,b.URL from (

	select * from 

	b_commission a where a.pid=0 

) a 

inner join 

(

    select * from B_COMMISSION a where a.PID<>0

) b 

on a.ID=b.PID";

            IEnumerable<dynamic> list = db.Database.SqlQuery<dynamic>(sql);



            foreach (var item in list)

            {

               //此时会报错，提示object未包含FID的定义。

                Console.WriteLine(item.FID);

            }

...全文

955 27 打赏收藏转发到动态举报

写回复

用AI写文章

27 条回复

切换为时间正序

请发表友善的回复…

发表回复

緣木求魚 2015-07-20

打赏
举报

【求助】我现在也碰到这问题了，楼主是怎么解决的。。。

garfieldzf 2015-01-30

打赏
举报

引用 22 楼 fly_to_the_winds 的回复:

请问楼主解决这个问题没有？

还没有，后来没再关注过，最近又想起来了。

garfieldzf 2015-01-30

打赏
举报

引用 21 楼 Coder_JetWu 的回复:

若使用sqlquery查询需要定义一个对应的entity 这个是很烦的我之前做的项目都是定义一个对应entity 现在做一个动态生成表也就是在运行时生成表或修改表结构的模块项目使用EF 其中的一个实现思路也是想通过dynamic 来实现

具体做法是什么样的？

吴明式 2015-01-23

打赏
举报

对这个问题，winner2050说的比较对。但有些情况如果能返回dynamic也是不错的。就像php中，以array为查询结果返回。 winer2050举例的情况，用ef的include各个外键属性是比较适合的。但项目如果所有数据都需要序列化，直接poco序列化有问题，而另外生成viewmodel不少人会觉得麻烦，使用codefirst，标注datamember虽然可以解决，但并不是所有人都喜欢codefirst。等等之类的ef解决不了的情况（可能我ef还不够了解）不用ef就是了，并不是所有情况ef都适用。比如需要垂直分表，我就不知ef如何实现，可能能实现吧，但这些情况，我不用ef就是了，人怎么能被尿憋死？

WoooXVi 2014-12-20

打赏
举报

我也想知道……

浮生若梦丶 2014-07-31

打赏
举报

请问楼主解决这个问题没有？

Coder_CaiNiao 2014-05-06

打赏
举报

若使用sqlquery查询需要定义一个对应的entity 这个是很烦的我之前做的项目都是定义一个对应entity 现在做一个动态生成表也就是在运行时生成表或修改表结构的模块项目使用EF 其中的一个实现思路也是想通过dynamic 来实现

david_88888 2013-09-11

打赏
举报

引用 14 楼 winner2050 的回复:

有时候做报表，用EF还真用不上。用dataset可能性高。但是不能因为特例放弃面向对象编程的基本做法。

用EF框架就是面向对角编程,用DataSet就不是了？请教

moonwrite 2013-09-11

打赏
举报

哪怕是只取表中的2个数据字段~，也使用表对应的Model~ 不要为了2个字段再创建一个实体~ 不就OK了~ 总得牺牲点什么~ 如果取其他表的数据，就用实体关联（导航属性）另外可以返回的是IQueryAble<T> 那么可以在需要数据的时候再查询（EF有延迟查询特性） var result=from x in (IQueryAble<T>)//这个是随便写的 where ..... select new{x.A,x.B}; //这样也只会从数据库拿两个字段 //这招在Webfrom还是蛮好使的，但在mvc中，view和Controller之间的Model必须早定义好，当然也可以用View.Bag，但是弱类型的~，没有智能提示，不喜欢 dynamic 这个是动态类型，也就是没有智能提示，也没有强类型检查~，不喜欢分享一下我个人看法，尽可能利用生成的Model，哪怕是多读点数据，必要时则自定义Model

garfieldzf 2013-09-11

打赏
举报

引用 15 楼 ycg_893 的回复:

楼主的想法是不是希望根据Sql推导出相应的动态类型和属性，这样的话在开发中就不需要为每个自定义的语句编写一个实体模型。

是的，我正是这个想法，这个问题相信大家在项目中肯定遇到过。

garfieldzf 2013-09-11

打赏
举报

引用 18 楼 moonwrite 的回复:

哪怕是只取表中的2个数据字段~，也使用表对应的Model~ 不要为了2个字段再创建一个实体~ 不就OK了~ 总得牺牲点什么~ 如果取其他表的数据，就用实体关联（导航属性）另外可以返回的是IQueryAble<T> 那么可以在需要数据的时候再查询（EF有延迟查询特性） var result=from x in (IQueryAble<T>)//这个是随便写的 where ..... select new{x.A,x.B}; //这样也只会从数据库拿两个字段 //这招在Webfrom还是蛮好使的，但在mvc中，view和Controller之间的Model必须早定义好，当然也可以用View.Bag，但是弱类型的~，没有智能提示，不喜欢 dynamic 这个是动态类型，也就是没有智能提示，也没有强类型检查~，不喜欢分享一下我个人看法，尽可能利用生成的Model，哪怕是多读点数据，必要时则自定义Model

做数据平台的话，像这样的业务Model太多。过多

winner2050 2013-09-10

打赏
举报

有时候做报表，用EF还真用不上。用dataset可能性高。但是不能因为特例放弃面向对象编程的基本做法。

garfieldzf 2013-09-10

打赏
举报

引用 3 楼 bwangel 的回复:

本来orm是为了避免写sql语句的。你举的例子全用了sql语句，这跟orm的初衷背道而驰呀。 dynamic是为了和外部组件交互而引入的。像你的这种场合，我看还不如直接返回一个DataSet.你连对象都不要了，还要搞个dynamic来冒充啥呢？

你的项目中也没有一个自定义查询？？？？？不佩服你不行

garfieldzf 2013-09-10

打赏
举报

引用 8 楼 winner2050 的回复:

[quote=引用楼主 LOVESONGFOREVER 的回复:] 项目中用的NH，加上现在关注的EF，都存在自定义查询的实体问题，也就是自定义查询时需要创建一个业务实体，那么这样的话尤其是对于数据管理平台来说Model层会相当庞大，我就体会到了。

从这点看出来你，把EF当作sql代码的另一种书写方式。我经常训人，胡乱建视图，好端端的东西给搞砸了。 EF 有导航属性在，根本不用像作视图一样，为各种需求联合不同表，暴露不同字段。 [/quote] 我不相信你的项目中一句自定义查询也么有，你的数据逻辑我也不方便评价，同时：我只是想就我平时遇到的问题提出一个解决办法。

garfieldzf 2013-09-10