下个版本的示例不要再用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乱七八糟的东西！

Stark11

新技术刚出来时，总是会被旧技术保守派攻击，但最终旧技术还是要被淘汰，这是历史趋势

夏雨雪(joe)

EF是必须的，至于一些复杂的查询什么的，可以使用存储过程实现。

Tiger

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

Mr.Wu

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

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

吉吉﹑

用EF才是趋势

Primates

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

Destiny

新技术、新框架的出现，意味着对传统的挑战。我们害怕它，是因为我们对它了解得还不够。

甘桂

条件 要想让一个数据库支持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三中数据库任意设置。就是用三层数据结构

甘桂

使用示例：  从 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三中数据库任意设置。就是用三层数据结构