下个版本的示例不要再用EF了。

甘桂

个人观点：让FINEUI发展起来，我们在数据核心处理部份不建议使用EF结构。
1、 相信没有完美的ORM，目前主流的NH，iBatis等等都是如此。
EF也不例外，运到复杂的关联查询的时候，用linq写那是非常困难的。就算能写出来，维护性和可读性也不及直接写sql。
2、EF最大的麻烦就是联合查询实现困难，它只是体现数据库的某个表，要多表的信息还得先在数据库中建视图，使用不便，还是直接SqlCommand用起来方便，否则用EF是给自己找麻烦。
3、我曾经对LINQ TO SQL感兴趣过，后来发现自动生存的SQL代码中，无法很好的处理Distinct语句，更不用说是用CASE WHEN了，于是我开始抛弃类似的SQL实体。不过那个CLR函数倒是很不错的改进，虽然比起Oracle晚了好几年，不过也算是有了这个功能了，写个自定义聚合函数让我查询效率倍增。
4、在EF中使用join，那么数据是怎么过滤的，是join之后过滤，还是join之前过滤。我希望join之后过滤，那么EF是不是会将表中所有数据先加载到内存中，然后join，最后执行过滤？如果是百万级以上的表，这样是不是太慢了，几乎不现实的做法。而我要是用SQL语句实现，过滤是在数据库中执行，效率明显提高，因为数据库就是用来处理数据库，在程序中执行数据库的部分功能就是降低效率，不可能有数据库中执行过滤筛选速度快。

夏雨雪(joe)

sanshi 发表于 2013-10-21 13:47
我还是看好EF的，EF6.0也出来了，第一个完全开源的版本。

用EF就要按照EF的逻辑去思考问题，在整个APPBOX ...

赞成，每个技术处理，不一定是完美的。复杂的处理，您可以用存储过程啊。

EF能够发展到6.0以上，说明他的优点是非常多的。

不要因为不够了解，就去否定它。

sanshi

我还是看好EF的，EF6.0也出来了，第一个完全开源的版本。

用EF就要按照EF的逻辑去思考问题，在整个APPBOX中，没有用到类似SQL的联合查询（JOIN来JOIN去的），简单Include搞定（看我的博客：http://www.cnblogs.com/sanshi/p/3277638.html）；而SQL中复杂的子查询也可以使用ANY 或者 ALL 等关键字实现（http://www.cnblogs.com/sanshi/p/3282833.html）。

本来我也觉得EF会很难，什么INNER JOIN、LEFT JOIN、子查询都该怎么实现呢？等仔细看了一端时间的EF文档，才发现我想多了。

秋收

非常赞同楼主观点：
1、FINEUI重点用于处理UI及其交互;
2、直接使用SQL语句，灵活方便，直观，便于维护，效率高;
3、如其学掌握ORM，还不如学习SQL简便
反正我一直直接使用SQL语句，不理睬什么EF、NH，iBatis乱七八糟的东西！

sanshi

欢迎大家参与讨论

binbin

同意，那些ORM最后解析后还是SQL语句，这本身就会耗掉一部分性能，而且对一些复杂查询支持的也不够好！！

Mr.Wu

呵呵，自从appbox3.0改为EF后，我也不知道怎么下手了，建议还是使用其它方式吧

小兵

从来都是直接SQL的，不会博主提到的什么NH，LingQ，EF东西。落后啊。

Mr.Wu

小兵 发表于 2013-10-21 15:44
从来都是直接SQL的，不会博主提到的什么NH，LingQ，EF东西。落后啊。

看来我更落后了

莮亾

“FINEUI重点用于处理UI及其交互” 这个观点我非常赞同！
吸引人的还是更多好用和实用的控件！

purplebolt

从来也是用SQL去实现,现在去看看博主的贴子,看看EF