FineUI 官方论坛

标题: 下个版本的示例不要再用EF了。 [打印本页]

作者: 甘桂 时间: 2013-10-21 10:51
标题: 下个版本的示例不要再用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语句实现，过滤是在数据库中执行，效率明显提高，因为数据库就是用来处理数据库，在程序中执行数据库的部分功能就是降低效率，不可能有数据库中执行过滤筛选速度快。

作者: sanshi 时间: 2013-10-21 11:11
欢迎大家参与讨论

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

作者: binbin 时间: 2013-10-21 12:37
同意，那些ORM最后解析后还是SQL语句，这本身就会耗掉一部分性能，而且对一些复杂查询支持的也不够好！！

作者: Mr.Wu 时间: 2013-10-21 13:04
呵呵，自从appbox3.0改为EF后，我也不知道怎么下手了，建议还是使用其它方式吧

作者: sanshi 时间: 2013-10-21 13:47
我还是看好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文档，才发现我想多了。

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

作者: Mr.Wu 时间: 2013-10-21 16:16

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

看来我更落后了

作者: 莮亾 时间: 2013-10-21 16:34
“FINEUI重点用于处理UI及其交互” 这个观点我非常赞同！
吸引人的还是更多好用和实用的控件！

作者: purplebolt 时间: 2013-10-21 17:38
从来也是用SQL去实现,现在去看看博主的贴子,看看EF

作者: erp8@live.cn 时间: 2013-10-21 20:58
个人认为:结合EF是大势所趋,推陈才能出新,
没有旧知识归零的痛苦,就没有凤凰浴火涅磐重生的收获.

当然,不用不熟,初级阶段,不熟悉LINEQ 时可以结合ADO.net 予以补充,
我就是这么做的.

作者: 最初的理想 时间: 2013-10-22 01:33
额...最初自己写三层，后来动软代码生成器，再后来 subsonic...现在大家都用什么？

作者: liko1688 时间: 2013-10-22 09:20
本帖最后由 liko1688 于 2013-10-22 09:21 编辑

EF migrate很方便，而且支援許多常用的数据库，程序完全不用改写很棒，
用sql command 还要搭适合的class library，且搭不同数据库程序多少要改一点很麻烦。
支持EF版。

作者: 部居晓杰 时间: 2013-10-22 09:38
我在烦怎么转ORACLE数据库，我项目里客户要求用ORACLE，现在总是转不过去，什么方法都试过了

作者: 夏雨雪(joe) 时间: 2013-10-22 11:39

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

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

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

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

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

作者: 夏雨雪(joe) 时间: 2013-10-22 11:41

部居晓杰发表于 2013-10-22 09:38
我在烦怎么转ORACLE数据库，我项目里客户要求用ORACLE，现在总是转不过去，什么方法都试过了 ...

可以参考一下ALinq

作者: 甘桂 时间: 2013-10-30 22:10
使用示例：从 Northwind 示例数据库生成完整 Entity Model。 EdmGen /mode:FullGeneration /project:Northwind /provider:System.Data.SqlClient /connectionstring:"server=.\sqlexpress;integrated security=true; database=northwind" 从 ssdl 文件开始生成 Entity Model。 EdmGen /mode:FromSSDLGeneration /inssdl:Northwind.ssdl /project:Northwind 验证 Entity Model。 EdmGen /mode:ValidateArtifacts /inssdl:Northwind.ssdl /inmsl:Northwind.msl /incsdl:Northwind.csdl 为什么要使用Entity Framework，限制条件及当前版本框架的问题优势通过对比上面图4与图2、图3我们可以很清楚的看到使用Entity Framework一个很大的好处，我们可以把实体类的定义由一个单独的项目使用C# class完成这样一种设计方式转变为使用xml文件定义并集成到数据访问层。在以往要在一个项目中动态创建实体，我所知的方法是把要添加的实体放入一个程序集，然后通过反射加载程序集。现在可以通过动态更改EDM的方法来增加实体并将其映射到数据库，后者是以前无法实现的。便于更改数据库，当更换数据库后，只需修改SSDL的定义，（如果数据库的表明有变动，也只需多修改MSL），对CSDL没有任何影响，从而也不需要对程序的BLL等上层部分做任何改动。条件要想让一个数据库支持Entity Framework，一个必要条件就是该数据库需提供相应的Entity Client Data Provider，这样才能将Entity SQL转换为针对此数据此数据库的SQL并交由ADO.NET来执行。当然该数据库还需要提供ADO.NET Data Provider。缺陷 Entity Framework技术的效率问题是其几乎唯一一个稍有不足之处。首先其将EntitySQL转换为SQL的方式属于解释性转换，性能较差。另外Entity Framework在每次应用启动时需要读取EDM，这个过程较慢（但在后续操作时，就不再存在这个问题）。本论坛的源码可以支持ACCESS，SQL SERVER ，ORCEL三中数据库任意设置。就是用三层数据结构

作者: 甘桂 时间: 2013-10-30 22:12
条件要想让一个数据库支持Entity Framework，一个必要条件就是该数据库需提供相应的Entity Client Data Provider，这样才能将Entity SQL转换为针对此数据此数据库的SQL并交由ADO.NET来执行。当然该数据库还需要提供ADO.NET Data Provider。缺陷 Entity Framework技术的效率问题是其几乎唯一一个稍有不足之处。首先其将EntitySQL转换为SQL的方式属于解释性转换，性能较差。另外Entity Framework在每次应用启动时需要读取EDM，这个过程较慢（但在后续操作时，就不再存在这个问题）。本论坛的源码可以支持ACCESS，SQL SERVER ，ORCEL三中数据库任意设置。就是用三层数据结构

作者: Destiny 时间: 2013-10-31 10:26
新技术、新框架的出现，意味着对传统的挑战。我们害怕它，是因为我们对它了解得还不够。

作者: Primates 时间: 2013-10-31 12:16
本帖最后由 Primates 于 2013-10-31 23:21 编辑

我支持楼主的观点，原因：
1、fineUI推广需要展示它自身原有的优点，千万不要受到其他技术干扰造成推广的障碍；
2、fineUI要得到推广，需要在“实际项目”中应用，而不仅仅只是“试验项目”应用；
3、绝大多数开发者，在做企业开发项目实战时，总体上更多、也是普遍使用自己熟悉的技术，来快速完成既定的功能。同时，在有时间的条件下，对项目某个细节才会琢磨一些新技术的应用。
4、微软的MSDN实例代码，都是很简单“原生”状态的代码，很直观，不会展现花哨的思路和技巧；
5、fineUI推广号称节省80%的界面开发精力，这也是众多fineUI拥趸所看中的，让开发者从“界面”中解放出来，然而在看fineUI示例时，其中的确有一些“花哨”的非fineUI代码技巧，干扰新手；
6、从纯技术角度来看：新技术的应用是值得的，EF也是有其自身的价值；
从商业推广的角度来看：新技术往往会让过去已有的、熟悉的经验价值降低；
从主题思想来看：我要推广A，可却包含着新技术B，难免会跑题、会干扰主题目的。
=========
以上仅为个人观点。

作者: 吉吉﹑ 时间: 2013-11-1 12:01
用EF才是趋势

作者: Mr.Wu 时间: 2014-7-16 11:33

liko1688 发表于 2013-10-22 09:20
EF migrate很方便，而且支援許多常用的数据库，程序完全不用改写很棒，
用sql command 还要搭适合的class l ...

看来支持的还是少数人啊，建议老大要么开个讲座指点一下Appbox搭配EF的相关用法，不然很多人（包括我）都是云里雾里的……

作者: Tiger 时间: 2014-7-16 17:44
我也太喜欢 LinQ 这东西刚出来的时候，我正好参加微软的TechEd大会，听了一点关于它的介绍，会后我找老师问了几个问题，基本当时都没回答上来，当然有个最主要的原因，是我因为排斥，所以根本没有深入看过LinqQ 所以只是一家之言

作者: 夏雨雪(joe) 时间: 2014-7-17 09:01
EF是必须的，至于一些复杂的查询什么的，可以使用存储过程实现。

作者: Stark11 时间: 2018-6-12 10:30
新技术刚出来时，总是会被旧技术保守派攻击，但最终旧技术还是要被淘汰，这是历史趋势

欢迎光临 FineUI 官方论坛 (https://fineui.com/bbs/)