我注意到，似乎对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到SQL)，因为它实际上允许我们通过属性而不是文件来定义映射。 LTE仅适用于外部文件。

回答

我对Linq to Entities的原则和Entity Framework都相当满意，但是对于它的当前化身，我确实有所保留。我确实承认，除了自学和非常小的方式之外，没有其他用途。灵活性水平似乎还不存在，但是我敢肯定会实现。一位MS技术传道者(伟大的职务)告诉我，EF是MS未来的战略选择。假设情况是这样，那么我只能看到在这个舞台上情况有所好转。

回答

也可能会有"第二名"的敌意。 MS与L2E一起推向市场的时间很晚，大约三年前，我本人就对ORM产生了兴趣，而MS在这一点上无处可寻。

我们中的许多人已经花时间学习另一个ORM(例如NHibernate)，并且已经习惯了一定级别和可用的功能，而这在L2E中尚不明显。

老实说，这种"第二名"的敌意并不是什么新鲜事，我不知道为什么MS不花更多的时间来支持已经存在的解决方案，我们在NAnt-> MSBuild and NUnit-> MsTest上已经看到了这一切。 ，如果每个人都接受更好且成熟的解决方案之一，并努力支持该解决方案，而不是一直在酝酿自己，那将节省很多时间和精力。

回答

对实体的仇恨是当之无愧的。该产品无法实现任何更复杂的目的，然后GU脚的演示者GU在其博客上使用了该产品。 EF还没准备好迎接黄金时段。微软只是无法在.BLOAT世界中获取正确的数据，它们似乎每次随风而改变数据范例。 FoxPro具有相同的基本数据核心已有20年的历史了。鉴于SQL Server使用了许多VFP数据技术，也许MSFT可以从可行的东西中学到一些有关处理数据和以数据为中心的语言的知识。