我注意到似乎对 Linq To Entities 有相当多的敌意,尤其是来自 Alt.Net 的人。我理解对更多“拖放”编程的阻力,但据我了解,Linq To Entities 不需要它。
我们目前正在使用Linq to SQL,并且我们正在使用DBML文档来定义它(一旦你得到十几个左右的表,设计器就很没用了。)
那么为什么同样的方法对 Linq To Entities 不起作用呢?
我注意到似乎对 Linq To Entities 有相当多的敌意,尤其是来自 Alt.Net 的人。我理解对更多“拖放”编程的阻力,但据我了解,Linq To Entities 不需要它。
我们目前正在使用Linq to SQL,并且我们正在使用DBML文档来定义它(一旦你得到十几个左右的表,设计器就很没用了。)
那么为什么同样的方法对 Linq To Entities 不起作用呢?
实际上,一旦开始深入研究,LTE 对于企业级框架完全没有用处。几乎没有继承支持的事实(在 LTS 中也是如此)导致大量冗余代码。此外,我将回到 LTS(Linq to SQL),因为它实际上允许您通过属性而不是文件来定义映射。LTE 仅适用于外部文件。
我不认为这是对它本身的想法的仇恨。只是人们不喜欢它的实施。
http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/
Linq to Entity 的仇恨是当之无愧的。这个产品没有任何比 GU 在他的博客上使用它的蹩脚演示更复杂的目的。英孚远未准备好迎接黄金时段。微软只是无法在 .BLOAT 世界中正确获取数据,他们似乎每次都在改变数据范式。FoxPro 已经存在 20 年了,具有相同的基本数据核心。鉴于 SQL Server 使用了很多 VFP 数据技术,或许 MSFT 可以从一些有用的东西中学习一些关于操作数据和以数据为中心的语言的知识。
我对 Linq to Entities 的原则和一般的实体框架非常满意,但我对它目前的化身持保留态度。不过,我确实坦率地承认,除了自我教育和非常小的方式之外,我没有以任何方式使用它。灵活性水平似乎还没有,但我相信它会到来。一位 MS 技术布道者(伟大的职位)告诉我,EF 是 MS 未来的战略选择。假设是这种情况,我只能看到这个领域的情况越来越好。
也可能有一点“第二名”的敌意。MS 在L2E 上上市很晚,大约三年前,我本人对 ORM 产生了兴趣,此时还无处可见 MS。
我们中的很多人已经花时间学习另一个 ORM(例如 NHibernate),并且已经习惯了某种级别和类型的可用功能,而这在 L2E 中还不明显。
老实说,这种“第二名”的敌意并不是什么老新闻,我不知道为什么 MS 不花更多时间支持已经到位的解决方案,我们以前在 NAnt -> MSBuild 和 NUnit -> MsTest 上已经看到了这一切,如果他们只是接受一种更好、更成熟的解决方案并努力支持它,而不是一直在酝酿自己的解决方案,这将为每个人节省大量的时间和精力。
我要补充一点,TPT 继承的 LTE 实现简直就是犯罪。在这里查看我的问题。
虽然我这样做了,但我相信许多已发表的 EF 专家至少部分是同谋。我还没有在 EF 上找到任何已发布的材料,警告不要查询基本类型。如果我要在我拥有的模型上尝试它,SQL Server 只是放弃了例外。
您的 SQL 语句的某些部分嵌套得太深。重写查询或将其分解为更小的查询。
我很想重写查询,但 LTE 免除了我的负担。谢谢(^不)