我注意到人们似乎对 Linq To Entities 有相当大的敌意,尤其是来自 Alt.Net 的人们。我理解对更多“拖放”编程的抵制,但根据我的理解,Linq To Entities 不需要它。

我们目前使用的是Linq to SQL,并且使用DBML文档来定义它(一旦你得到了十几个左右的表,设计器就毫无用处了。)

那么为什么同样的方法不适用于 Linq To Entities 呢?

有帮助吗?

解决方案

我不认为这是对 主意 它本身。只是人们不喜欢 执行 它的。

http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

其他提示

事实上,一旦你开始深入研究,LTE 对于企业级框架来说是完全没有用的。事实上,继承支持非常少(LTS 中也是如此),这导致了很多冗余代码。另外,我将回到 LTS (Linq to SQL),因为它实际上允许您通过属性而不是文件来定义映射。LTE 仅适用于外部文件。

对 Linq to Entity 的憎恨是当之无愧的。该产品无法实现比 GU 在他的博客上使用它的蹩脚演示更复杂的用途。EF 还远没有为黄金时段做好准备。微软无法在 .BLOAT 世界中获得正确的数据,他们似乎每次风一吹都会改变数据范式。FoxPro 已经存在 20 年了,具有相同的基本数据核心。鉴于 SQL Server 使用了大量的 VFP 数据技术,也许 MSFT 可以从一些有效的东西中学到一些关于操作数据和以数据为中心的语言的知识。

我对 Linq to Entities 的原则以及一般的实体框架非常感兴趣,但我对其当前的版本确实持保留态度。不过,我坦率地承认,除了自学和非常小的方式之外,我并没有使用它。灵活性水平似乎还没有达到,但我相信它会到来。一位 MS 技术布道者(很棒的职位)告诉我,EF 是 MS 未来的战略选择。假设情况确实如此,我只能看到这个领域的情况正在变得更好。

也可能存在一些“第二名”的敌意。女士是 非常 L2E 进入市场较晚,大约三年前我自己就开始对 ORM 感兴趣,而此时 MS 还没有出现。

我们中的很多人已经花时间学习了另一种 ORM(例如 NHibernate),并习惯了某种级别和类型的可用功能,而这在 L2E 中还不明显。

说实话,这种“第二名”的敌意并不是什么旧闻,我不知道为什么 MS 不花更多时间支持已经到位的解决方案,我们之前已经通过 NAnt -> MSBuild 和 NUnit -> MsTest 看到了这一切,如果他们只是接受一种更好、更成熟的解决方案并努力支持它,而不是一直自己酝酿,那么每个人都会节省大量的时间和精力。

我想补充一点,LTE 实现 TPT 继承无异于犯罪。看我的问题 这里.

当我这样做的时候,我相信很多人 EF 专家发表 至少部分是同谋。我还没有找到任何有关 EF 的已发表材料警告不要查询基类型。如果我在我拥有的模型上尝试它,SQL Server 就会放弃并抛出异常。

SQL语句的某些部分嵌套得太深了。重写查询或将其分解为较小的查询。

我很想重写该查询,但 LTE 免除了我的负担。谢谢(^不是)

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top